Не так давно мы писали о протоколе VI/JSON от VMware для управления инфраструктурой vSphere. В то же время, у VMware в последнее время появилось много чего еще нового в сфере средств для автоматизации управления виртуальной инфраструктурой, о будущем которых мы сегодня и поговорим, обратив внимание на такие интерфейсы, как API, JSON, OpenAPI.

1. VMware vSphere API

VMware vSphere за последние годы стала значительно более сложным продуктом и теперь предлагает несколько разных типов API-технологий. Наиболее значимыми сегодня являются:

• vSphere Web Services API, который использует протокол SOAP
• vSphere Automation API, который использует принципы проектирования REST

Наличие нескольких API добавляет сложности в управление и эксплуатацию сложных сред. Эта сложность проявляется в разных аспектах, начиная с необходимости в нескольких инструментах, знаниях и навыках, в зависимости от API. Кроме того, разные API "висят" на разных эндпоинтах и требуют разные механизмы аутентификации по историческим причинам и для обеспечения обратной совместимости.

Обе категории API документированы отдельно, каждая со своими справочными руководствами и примерами кода. Это может вызвать путаницу для администраторов, поскольку они часто предполагают, что должны выбирать между REST API или SOAP API, но на самом деле им нужно использовать оба. REST не является заменой для SOAP API, но дополняет его.

В плане API компания VMware работает в трех основных направлениях:

• Упрощение использования API
• Упрощение документации
• Улучшение опыта разработчиков и унификация протоколов и наборов инструментов

Основные ресурсы, с которых надо начать знакомство с этими API, это:

• vSphere Automation REST API Programming Guide
• vSphere Web Services Programming Guide
• Understanding the vSphere Automation API
• Code Samples

2. Протокол JSON для Web Services API

Во-первых, начиная с vSphere 8 Update 1, был введен новый протокол JSON для всех Web Services API в VMware vSphere. Это помогает унифицировать опыт разработки, позволяя разработчикам использовать общие инструменты, и преобразует SOAP API для применения более REST-подобного подхода. Этот JSON API в vSphere 8 Update 1 и новее предоставляет полный набор функциональных возможностей, предлагаемых традиционным vim25 SOAP API.

Во-вторых, были сохранены та же структура, управляемые объекты и имена методов, чтобы клиенты могли перенести существующие решения для автоматизации на новый протокол JSON с минимальными изменениями.

Наконец, VMware предлагает спецификации OpenAPI 3.0 в дополнение к документации по JSON API виртуальной инфраструктуры. VMware также ведет работу по объединению документацию по JSON API с документацией по Automation API, где задокументированы все REST-сервисы. Это приближает момент создания единого места для поиска документации клиентами.

3. Формат OpenAPI 3.0

В будущем VMware перенесет оставшиеся публичные интерфейсы SOAP-сервисов (SPBM, SMS, EAM, VLSM) на эти же форматы, предоставляя спецификации OpenAPI 3.0 для каждого из них и интеграцию с документацией REST API.

После этого следующим улучшением будет предоставление единого механизма аутентификации для REST API и нового протокола JSON для SOAP API. Это упростит создание решений для автоматизации и обеспечит общую сессию для всех сервисов vSphere.

Окончательным шагом на этом пути улучшения будет предоставление всех сервисов через единый эндпоинт, с которым администраторы смогут вызывать все API vSphere. Это значительно упростит использование API в vSphere и обеспечит более качественное документирование, тем самым улучшая опыт разработки.

Нашелся очень интересный ресурс - вебсайт Operationalize Your World (OYW), где рассказано о современных методах управления виртуальной инфраструктурой VMware vSphere. Помимо этого, там есть очень много всего полезного, в том числе и для загрузки.

Все материалы по данной теме собраны в одном месте и состоят из следующих компонентов:

• Презентация PowerPoint - она используется для обсуждений внутри компании и для возможности аудитории адаптировать и представить фреймворк внутри компании CIO и командам, отвечающим за приложения.
• Набор инструментов Aria (vRealize) Operations - он состоит из дэшбордов, обзоров, суперметрик и алертов, которые вы можете импортировать в свою инфраструктуру. Он создан на основе актуальной версии vRealize Operations. Эти инструменты не тестировались на более ранних версиях, поэтому сначала обновите вашу инфраструктуру до последней версии.
• Книга - представляет собой редактируемый документ в формате Microsoft Word. Это документация OYW, которую клиенты могут принять и адаптировать в качестве своего внутреннего руководства по эксплуатации.
• Сайт VMwareOpsGuide - он охватывает больше, чем книга, но содержание сайта немного отстает, поскольку требуется время и усилия для ручной синхронизации сотен страниц, которые обновляются автором каждый месяц.

Собственно книга носит полное название "vSphere Metrics - Deep dive into VMware vCenter and ESXi performance and capacity counters" и представляет собой документ на 211 страницах.

Материалы книги абсолютно бесплатны и полностью Open Source. То есть, вы можете взять любые фрагменты из этой книги, изменить как нужно под нужды вашей организации (например, для руководств по эксплуатации) и использовать их без ограничения.

В общем, очень и очень полезный ресурс!

Одной из сильных сторон VMware vSphere является обширное количество API, которые позволяют управлять платформой. Более тысячи API, варьирующиеся от основных операций с виртуальными машинами до виртуализации хранилищ и сетей, от кластеризации до управления ресурсами, позволяют организациям любого размера настраивать vSphere под свои конкретные потребности и автоматизировать различные рабочие процессы для экономии времени и средств.

С момента их появления более 15 лет назад, API управления виртуальной инфраструктурой (VI) обрели широкое применение. Множество продуктов и бесчисленное количество скриптов разработаны с учетом этих API, и многие разработчики знакомы с их моделью разработки. В то же время, VI API основаны на протоколе SOAP, который в свою очередь разработан на основе XML. Несмотря на свою мощь, за годы XML доказал свою сложность как формат данных, имеющий свою долю проблем с безопасностью. Учитывая эти проблемы, разработчики и системные дизайнеры прибегают к JSON в качестве замены XML в области API.

Чтобы удовлетворить спрос и облегчить интеграцию в окружения, работающие только с JSON, начиная от веб-браузеров и до современных языков программирования, таких как Go, VMware представила новый протокол, основанный на JSON и похожий на REST, под названием VI/JSON.

Новый протокол является современной альтернативой устаревшему SOAP и предоставляет те же VI API на тех же эндпоинтах, с той же моделью безопасности. Одной из главных целей нового протокола VI/JSON является максимальное облегчение перехода от SOAP для новых пользователей VI API. Кроме того, для приложений, основанных на SDK, миграция на VI/JSON может быть выполнена полностью на платформе с минимальными изменениями в приложении.

В дополнение к полной обратной совместимости API, новый протокол предоставляет прямой доступ к так "managed properties" - почти 300 типов записей, представляющих состояние различных виртуализованных элементов, управляемых vSphere, начиная от виртуальных машин до сетей, хостов, кластеров и т.д. Ранее управляемые свойства были доступны только косвенно через многофункциональный инструмент Property Collector. Сегодня простой HTTP GET-запрос может получить доступ ко всем управляемым свойствам.

Для VI/JSON, похожесть на REST означает, что управляемые ресурсы и операции кодируются в URL-адресе запроса, а не в теле сообщения, как требуется в SOAP. Это изменение предоставляет множество преимуществ: упрощает интеграцию в сетевых экранах на уровне API, облегчает анализ трафика и упрощает написание скриптов. Аналогично, кодировка данных на основе JSON облегчит разработку для многих пользователей VI API.

И наконец, улучшены также и аспекты безопасности. Вместо использования HTTP-кук для идентификации сессии, новый протокол использует специальный HTTP-заголовок, предотвращающий классическую атаку, известную как межсайтовая подделка запроса (Cross-Site Request Forgery), когда третья сторона может украсть идентификационные данные пользователя.

Чтобы дать представление о новом протоколе, вот такой запрос может быть использован для включения виртуальной машины (заголовки протокола HTTP опущены для краткости):

POST /sdk/vim25/8.0.1.0/VirtualMachine/vm-42/PowerOnVM_Task

Эквивалентный запрос SOAP выглядит следующим образом. Обратите также внимание на обязательное тело, которое не требуется для простых запросов VI/JSON.

POST /sdk

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope ...>
    <soapenv:Body>
       <PowerOnVM_Task xmlns="urn:vim25">
          <_this versionId="8.0.1.0" type="VirtualMachine">vm-42</_this>
       </PowerOnVM_Task>
    </soapenv:Body>
</soapenv:Envelope>

Новый протокол уже включен в состав последнего релиза VMware vSphere 8 Update 1. Более подробную информацию по работе с ним вы можете получить здесь.

На днях компания VMware сделала анонс большого обновления своей архитектуры VMware Cloud Foundation версии 5.0. Этот крупный релиз платформы предлагает дополнительную масштабируемость, безопасность и несколько ключевых улучшений, которые направлены на соответствие требованиям для инфраструктур IaaS, упрощают развертывание облачных услуг на собственных площадках и обеспечивают дополнительную защиту от кибератак.

Основные компоненты VCF 5.0 выглядят следующим образом:

Напомним, что VCF - это главное программное комплексное инфраструктурное решение VMware, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О прошлой версии этой платформы 4.5 мы писали вот тут.

Релиз VMware Cloud Foundation 5.0 является результатом многих месяцев разработки и тестирования. В этот период испытывались последние версии vSphere 8.0 Update 1a для управления рабочей нагрузкой, vSAN 8.0 Update 1a для масштабируемого хранения, NSX 4.1 для сетевых решений и vRealize Lifecycle Manager 8.10 (Aria) для управления облаками.

Давайте посмотрим, что новой в обновленной архитектуре VCF 5:

1. Улучшения SDDC Manager

VMware Cloud Foundation 5.0 включает новую функцию под названием Isolated SSO Workload Domains, которая позволяет администраторам настроить новые области рабочей нагрузки, используя отдельный экземпляр Single Sign On (SSO). Этот сценарий полезен для крупных предприятий, которым необходима изоляция рабочих нагрузок, а также для сервис-провайдеров, которые могут выделять области рабочей нагрузки различным клиентам с их собственными доменами SSO. В каждом изолированном домене SSO настраивается собственный экземпляр NSX. Дополнительное преимущество заключается в том, что настройка областей рабочей нагрузки как изолированной области рабочей нагрузки также дает возможность настроить и отдельного поставщика идентификации (Active Directory или LDAP).

2. Масштабирование области рабочей нагрузки

Для Workload domain scaling число изолированных областей рабочей нагрузки увеличено с 15 до 25 в рамках одного экземпляра VMware Cloud Foundation. Обратите внимание, что области рабочей нагрузки, настроенные на использование общего домена управления SSO, по-прежнему ограничены максимумом 15 доменов. Дополнительное масштабирование становится возможным благодаря параллелизации задач с целью уменьшения времени на добавление областей рабочей нагрузки в экземпляр VMware Cloud Foundation.

3. Улучшения платформы и масштабирования VMware Cloud Foundation

Если посмотреть на новые возможности, представленные в VMware Cloud Foundation 5.0, улучшения платформы vSphere / vSAN и масштабирования, являются самыми ожидаемыми запросами функций от клиентов сред VMware Cloud Foundation. Также важно подчеркнуть, что обновления до VMware Cloud Foundation 5.0 являются прямыми, с возможностью пропуска обновлений версий VMware Cloud Foundation 4.3, 4.4 и 4.5.

4. Проверки SDDC Manager Context Aware Pre-Checks и дрейф конфигурации (Configuration Drift)

Для обеспечения лучшего пользовательского опыта менеджер SDDC использует предварительные контекстные проверки (Pre-Checks), чтобы убедиться, что стек инфраструктуры готов принять желаемое обновление. Рабочие процессы, построенные в VMware Cloud Foundation 5.0, обеспечивают обновление развертывания до желаемой версии VMware Cloud Foundation в правильном порядке, начиная с компонентов домена управления.

В VMware Cloud Foundation 5.0 предварительные проверки менеджера SDDC были улучшены и теперь учитывают контекст. После того как менеджер SDDC был установлен или обновлен до версии 5.0, администраторы могут выбрать обновление своих доменов VMware Cloud Foundation до новой целевой версии VMware Cloud Foundation 5.x (при необходимости пропуская релизы), что дает администраторам возможность провести предварительную проверку для определенного релиза VMware Cloud Foundation или выполнить предварительную проверку "готовности к общему обновлению", чтобы обеспечить общую готовность платформы.

С VMware Cloud Foundation 5.0, менеджер SDDC также позволяет администраторам просматривать любые изменения в конфигурации, которые устанавливаются в рамках обновления, чтобы обеспечить дополнительную видимость и помочь администраторам лучше понять новые функции и возможности, а также влияние, которое они могут оказать на их текущие развертывания.

Более подробно о новых возможностях VMware Cloud Foundation 5.0 также можно почитать в следующих статьях:

• Announcing VMware Cloud Foundation 5.0
• What’s New with vSphere and vSAN in VCF 5.0
• What’s New with NSX in VMware Cloud Foundation 5.0
• What’s New with vRealize Suite in VMware Cloud Foundation 5.0
• VMware Cloud Foundation 5.0 Release Notes

Вильям Лам опубликовал интересную статью о шаблонах виртуальных машин (VM Templates), разъясняющую некоторые возможности по их использованию в библиотеках контента.

Часто неправильно понимаемой возможностью библиотеки контента vSphere является управление и распространение шаблонов виртуальных машин (VM Templates), которая была представлена в vSphere 6.7 Update 2.

Для библиотек контента в vSphere 5.0 контент распространялся с использованием репликации на основе запроса, при которой на клиентском vCenter Server настраивалась подписка на контент сервера-издателя vCenter Server, а затем контент скачивался на сервер подписчика, как показано на рисунке ниже.

Эта первоначальная архитектура библиотеки контента vSphere упрощала любому vCenter Server, независимо от его домена Single Sign-On, создание подписки и загрузку контента (файлы ISO, OVF/OVA и другие) из vSphere Content Library сервера-издателя.

Создание подписки на библиотеку контента vSphere полностью управлялось подписывающимся vCenter Server, если он знал URL подписки и учетные данные для подключения к серверу-издателю vCenter Server. Хотя это упрощало подписку на контент из библиотеки контента vSphere для всех, это также означало, что для больших организаций с множеством серверов vCenter Server требовалась дополнительная задача по настройке каждого подписывающегося vCenter Server.

После того как контент был синхронизирован с подписчиком vCenter Server, не было простого способа контролировать, какие пользователи могут развертывать определенные OVF/OVA из библиотеки контента vSphere, что может быть проблемой для организаций, которые требуют тонкого контроля доступа к развертыванию рабочих нагрузок. Как гарантировать, что конкретные пользователи/группы развертывают подходящие или последние образы?

Когда возможность управления шаблонами VMTX была добавлена в библиотеку контента vSphere, это не только ввело новую функцию Check-In/Check-Out для шаблонов виртуальных машин, но и добавило новый метод управления распространением образов виртуальных машин через несколько серверов vCenter с использованием новой репликации на основе push, которая исходит от сервера-издателя vCenter Server.

Вместо того чтобы идти на каждый подписывающийся vCenter Server для создания подписки на библиотеку контента vSphere, теперь вы можете управлять всеми подписками непосредственно с сервера-издателя vCenter Server. Этот дополнительный метод репликации библиотеки контента vSphere требует, чтобы все серверы vCenter Server, которые хотят подписаться на образы VMTX, участвовали либо в Enhanced Linked Mode (ELM), либо в Hybrid Linked Mode (HLM), где онпремизный vCenter Server публикует контент на vCenter Server VMware Cloud на AWS (в обратную сторону пока не поддерживается).

Поскольку подписка на библиотеку контента vSphere управляется и настраивается на сервере-издателе vCenter Server, должно существовать доверие между сервером-издателем и сервером-подписчиком vCenter Server, чтобы иметь возможность создавать подписку с сервера-издателя vCenter Server, и именно поэтому требуется один из вариантов Linked-режимов, чтобы иметь возможность использовать новую возможность синхронизации VTMX.

Имея такое сопряжение, чтобы управлять и создавать подписки на ваши серверы-подписчики vCenter Server, включая образы VMTX, вам нужно выбрать желаемую библиотеку контента vSphere на вашем сервере-издателе vCenter Server и в новой вкладке "Subscriptions", как показано на скриншоте ниже.

Хотя при использовании новой функции VMTX в библиотеке контента vSphere есть некоторые узкие места, есть и большие преимущества перед управлением традиционными образами OVF/OVA. Некоторые администраторы знают, что нет способа контролировать, каким пользователям разрешено развертывать из конкретных образов OVF/OVA из библиотеки контента vSphere.

С VMTX у вас на самом деле есть возможность назначать детализированные права пользователям и группам, которые определяют, кто может видеть и развертывать конкретные образы VMTX, что является результатом того, что образ VMTX является частью инвентаря vSphere, что означает, что вы получаете преимущества от механизма прав vCenter Server.

Ниже приведен пример, где есть два образа VMTX: Photon-3.0 и Photon-4.0 в одной библиотеке контента vSphere, и права назначаются таким образом, что они соответственно отображаются на пользователя lob1-user и lob2-user, которым затем разрешено развертывать на основе прав, которые усатновлены на образы VMTX.

Кроме того, мы можем также ограничить, какой контент должен видеть конкретный подписывающийся vCenter Server, особенно если у ваших развертываний vCenter Server есть различные требования по контенту. С моделью на основе pull, все пользователи в подписывающихся серверах vCenter Server смогут видеть только все OVF/OVA из опубликованной библиотеки контента vSphere, и это может быть или не быть желаемым результатом в зависимости от потребностей вашей организации.

Альтернативный подход к ограничению доступа к OVF/OVA заключается в создании нескольких библиотек контента vSphere с сервера-издателя vCenter Server, но это может привести к дублированию контента, который должен быть в нескольких библиотеках, что потребляет дополнительное место хранения и добавляет дополнительную сложность.

С новым же подходом вы можете управлять одной библиотекой контента vSphere со всеми желаемыми VMTX, а затем использовать права vSphere для предоставления дополнительного контроля доступа в каждом подписывающемся vCenter Server. Наконец, чтобы гарантировать, что каждый подписывающийся vCenter Server не загружает ненужные образы VMTX, которые не могут быть использованы, вы всегда должны рассматривать возможность включения настройки "Загрузка контента библиотеки по мере необходимости" и предварительно загружать только тот контент, который, как вы знаете, может или будет использоваться подписывающимся vCenter Server.

Мы еще не рассказывали о новых функциях по обнаружению виртуальных машин-зомби, над которыми компания VMware ведет работу уже довольно давно. Между тем, эти функции могут быть очень и очень полезны в больших инфраструктурах.

VMware определяет "зомби" как виртуальные машины и серверы, которые изначально были развернуты для конкретной цели, но больше не выполняют полезной работы. VMware обнаружила, что зомби-ВМ распространены в облачных средах клиентов (а это от 15% до > 50% от всех серверов и виртуальных машин).

Такая ситуация может влечет за собой лишние затраты и угрозы в плане безопасности, а также огромное воздействие на окружающую среду в виде неиспользуемой инфраструктурной мощности, потребления энергии и выбросов углерода.

Например, в 2019 году, завершая миграцию дата-центра, VMware обнаружила, что 47% ее виртуальных машин не используются и были устаревшими! Зомби-ВМ так распространены, потому что их легко создать (подумайте, сколько у вас зомби-приложений на телефоне?), но их может быть сложно найти. Продукты VMware vRealize Operations и CloudHealth могут помочь найти те, которые выключены или имеют низкую или нулевую загрузку процессора. Однако, многие зомби-ВМ имеют некую остаточную активность, которая вспомогательна по отношению к основному приложению, такую как сканирование на вирусы, обновление патчей и резервное копирование. Современные детекторы пропустят эти "ползучие зомби", потому что, основываясь на их активности, они выглядят так, будто они могут выполнять продуктивную работу.

Чтобы решить эту проблему, VMware тестирует подход, который отслеживает виртуальные машины на протяжении всего их существования и наблюдает за резким и постоянным снижением их активности. Любая сезонная и квазипериодическая активность при этом учитывается. Если оставшаяся активность постоянно низкая, то виртуальная машина становится потенциальным "зомби" и подвергается дальнейшему наблюдению.

Совпадающее поведение зомби-ВМ по нескольким метрикам активности подкрепляет ее статус. Поскольку работающие с полезной нагрузкой виртуальные машины могут оставаться неактивными на длительные периоды (недели или месяцы), система обнаружения зомби-ВМ терпелива, чтобы минимизировать ложные срабатывания. Если виртуальная машина снова становится активной, она удаляется из списка потенциальных зомби-ВМ. В конечном итоге, целью VMware является определение такх машин в облачных средах клиентов, выделение связанных с ними финансовых и углеродных затрат и предоставление вариантов устранения (например, с помощью Virtual Machine Desired State Configuration) для снижения затрат и освобождения ресурсов. VMware находится в процессе тестирования этого на данных клиентов, чтобы уточнить алгоритм обнаружения.

На картинке выше, ряд метрик отражает использование ресурсов с резким падением с около 80% до нового стабильного состояния - около 20%. Красные пунктирные вертикальные столбцы показывают область аномалии смены точек, а фиолетовые точки указывают на путь среднего предиктора с уменьшающейся величиной через область аномалии. Серые треки - это асимметричные погрешности вокруг среднего предиктора с уменьшающейся величиной. В какой-то момент ряд достаточно выравнивается, чтобы подтвердить постоянное, более низкое состояние активности. В этом случае "новая норма" выглядит как остаточный фон, состоящий из периодической активности малой амплитуды. Этот остаточный сигнал анализируется на предмет известного класса непродуктивного фона, такого как регулярное сканирование на вирусы или накатывание патчей.

Пока эти функции еще не внедрены в VMware vSphere, но их появление ожидается уже в самом ближайшем будущем.

Компания VMware объявила о том, что ее первый пакет обновления новой версии платформы VMware vSphere 8 Update 1 вошел в стадию General Availability (GA). Напомним, что первоначальная доступность (Initial Availability, IA) этого продукта была анонсирована в марте этого года, а о его новых возможностях мы писали вот тут. В апреле vSphere 8 U1 стала доступна для загрузки.

Напомним, что первоначальный IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать обратную связь от первых клиентов и партнеров (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени публикуются все найденные важные проблемы. С момента выхода GA-релиза платформу можно смело обновлять, так как за прошедший месяц-полтора ничего критичного в новой версии найдено не было.

Упомянем также, что в модели релизов Initial Availability (IA) / General Availability (GA) для платформы VMware vSphere 8 Update 1 и далее произошли некоторые изменения. А именно: так как подавляющее большинство критических багов было связано с работой гипервизора ESXi, то теперь сервер упрвления vCenter сразу выходит в статусе GA, а вот входящие в него хосты ESXi - в статусе IA.

Теперь же VMware ESXi 8.0 вышел в General Availability, его можно смело скачивать и делать апгрейд своей инфраструктуры:

Обратите внимание, что для скачивания доступны апрельские образы, то есть в них ничего не изменилось - данный релиз это просто объявление о General Availability без обновления самих установочных образов. С момента доступности в рамках IA платформа vSphere была развернута на десятках тысяч серверов (данные системы телеметрии CEIP), и ничего критичного за это время не произошло. Кстати, критические ошибки этого обновления отслеживаются в KB 90026.

Также напомним наши статьи, связанные с выходом обновления vSphere 8 Update 1:

• Анонсировано обновление платформы VMware vSphere 8.0 Update 1
• Для чего нужны и как работают профили Configuration Profiles в VMware vSphere 8 Update 1
• Изменение в модели релизов Initial Availability (IA) / General Availability (GA) для платформы VMware vSphere 8 Update 1 и далее
• Новые возможности VMware vSAN 8 Update 1
• Новые возможности Core Storage в VMware vSphere 8 Update 1

Многие администраторы помнят, что при анонсе платформы vSphere 8 в прошлом году компания VMware представила технологическое превью технологии Configuration Profiles, которая пришла на смену устаревшему механизму Host Profiles. В недавно состоявшемся релизе vSphere 8 Update 1 движок Configuration Profiles стал полностью поддерживаться в производственной среде. Теперь администраторы могут начать использование этой функциональности и смигрировать в эту среду...

На днях компания VMware выпустила первую версию плагина, предназначенного для исполнения типовых сценариев PowerCLI - Power Actions 1.0. Об этом средстве мы уже упоминали, когда в начале 2021 года компания VMware выпустила обновленную версию vSphere HTML5 Web Client.

Power Actions - это плагин клиента vSphere, который обеспечивает простой способ исполнения скриптов PowerCLI с пользователями, не имеющими опыта работы с PowerShell. Это средство также предоставляет библиотеку скриптов, куда вы можете загрузить готовые скрипты PowerCLI, которые вы хотите сделать доступными для всех сотрудников вашей организации. Пользователи могут легко выполнить эти скрипты, используя удобный пользовательский интерфейс для указания параметров скрипта. Это обеспечивает мощный механизм расширения клиента vSphere с помощью настраиваемых сценариев PowerCLI.

А что насчет безопасности и прав доступа? Все скрипты выполняются с использованием прав пользователя, который вошел в клиент vSphere. Таким образом, если у пользователя нет разрешения на выполнение определенных операций, он не сможет выполнить эти операции с помощью Power Actions.

1. Установка

Power Actions распространяется в виде виртуального модуля (Virtual Appliance). Вы можете загрузить файл OVA со страницы Power Actions на сайте VMware Labs. Там же вы можете загрузить полное руководство пользователя, которое содержит подробные инструкции по установке. После установки Power Actions вы можете использовать его через Developer Center в клиенте vSphere.

2. Библиотека сценариев

Основная функция Power Actions - запуск сценариев из вашей библиотеки сценариев. Поэтому первым делом нужно создать библиотеку сценариев и загрузить в нее ваши скрипты.

Библиотеки сценариев на самом деле являются библиотеками контента, так что любую библиотеку контента можно использовать как библиотеку сценариев. Если у вас нет библиотеки контента, вы можете создать новую с помощью PowerCLI или клиента vSphere. Следующим шагом будет импорт ваших сценариев в библиотеку сценариев. Вы можете загружать сценарии по одному через клиент vSphere или целые коллекции сценариев через PowerCLI.

3. Запуск скриптов

После того, как вы загрузили свои скрипты в библиотеку, вы можете начать запускать их. У вас есть два варианта запуска скрипта - непосредственно из библиотеки или через контекстное меню. В обоих случаях, когда вы выполняете скрипт с параметрами, вам будет предложено ввести их. Однако, когда вы запускаете скрипт из контекстного меню, некоторые параметры будут автоматически заполнены для удобства.

Давайте более подробно рассмотрим, как это работает. В нашей библиотеке скриптов Power Actions мы импортировали простой скрипт PowerCLI, который создает снапшоты коллекции виртуальных машин. Вот как выглядит этот скрипт:

param (
    [Parameter(Mandatory=$true)]
    [VMware.VimAutomation.ViCore.Types.V1.Inventory.VirtualMachine[]] $vms, 
    [Parameter(Mandatory=$true)]
    [string] $snapshotName)
 
foreach ($vm in $vms) {
    New-SnapShot -VM $vm -Name $snapshotName
}
	

Когда мы запустили сценарий из библиотеки, мы получим диалог, в котором нам нужно указать обязательные параметры:

Если мы хотим выполнить сценарий из контекстного меню, мы можем кликнуть правой кнопкой по виртуальной машине и выбрать "Power Actions" -> "Run script".

В итоге, мы получим диалог, где нужно выбрать скрипт для исполнения, и потом нам нужно будет ввести параметры. В этом случае в список параметров будут автоматически добавлены параметры ВМ, для которой мы вызвали контекстное меню:

4. Мониторинг исполнения сценариев и просмотр результатов

На следующем экране Power Actions мы увидим представление "Script run". Здесь мы можем отслеживать выполнение скриптов и просматривать результаты исполнения. Также на этой странице можно остановить выполнение сценария.

5. Консоль сценария

Еще одна полезная возможность Power Actions - это встроенная консоль PowerShell с последней предустановленной версией PowerCLI. Когда вы отроете консоль, она автоматически соединится с vCenter Server, используя текущий пользовательский аккаунт vSphere Client. Вы можете использовать эту консоль для выполнения отдельных команд или готовых командлетов. Имейте в виду, если вы переключитесь на другое представление vSphere Client или запустите еще один экземпляр Power Actions, а потом вернетесь в консоль, то ваша сессия будет создана снова, а все переменные из памяти прошлого сеанса будут потеряны.

Скачать виртуальный модуль Power Actions и документацию к нему можно по этой ссылке.

Мы уже много писали о том, что после выхода платформы vSphere 8 компания VMware перешла на модель релизов Initial Availability (IA) / General Availability (GA). IA-релиз - это полностью Enterprise-ready продукт, который соответствует всем промышленным стандартам VMware уровня релиза GA, но доступен он, как правило, на 4-6 недель раньше, чтобы собрать обратную связь от первых клиентов и партнеров (и, конечно же, критичные для инфраструктуры баги). В этот промежуток времени публикуются все найденные важные проблемы.

Одна из причин такого перехода - это то, что раньше релиз мажорной версии многие пользователи пропускали, ожидая хотя бы Update 1, который часто исправлял некоторые проблемы первоначального релиза новой версии платформы. Теперь у пользователей будет достаточно времени, чтобы оценить - произошло ли за эти 1-2 месяца что-то критичное, и можно ли обновлять свои хост-серверы. Такая схема должна работать эффективнее, так как до очередного пакета Update X проходит в среднем полгода.

Таким образом, общая схема выпусков IA/GA для VMware vSphere теперь выглядит так:

Если говорить конкретно, то версия vSphere 8 IA вышла в октябре прошлого года, а версия vSphere 8 GA была доступна через месяц - в ноябре 2022 года. Между этими двумя релизами не было сообщений о критических ошибках и проблемах, а значит вроде как новая схема работает неплохо. Кстати, установочный ISO-образ сервера ESXi 8.0 IA ушел в релиз как GA без изменений.

Теперь, после анонса первого пакета обновлений vSphere 8 Update 1, компания VMware решила эту схему немного доработать. Так как подавляющее большинство критических багов было связано с работой гипервизора ESXi, то теперь сервер упрвления vCenter будет выходить в статусе GA, а вот входящие в него хосты - в статусе IA.

Надо еще учесть, что vCenter обновляется чаще, чем ESXi, а также не является критической точкой инфраструктуры - виртуальные машины могут работать некоторое время и без него, а сам виртуальный модуль vCSA (vCenter Server Appliance) можно обновить достаточно просто, не затрагивая корневые инфраструктурные сервисы.

В итоге: выпуск VMware vSphere 8 Update 1 будет включать в себя ESXi 8.0 Update 1 IA и vCenter 8.0 Update 1 GA.

Недавно мы писали об анонсированных новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 1, выход которой ожидается в ближайшее время. Параллельно с этим компания VMware объявила и о выпуске новой версии решения VMware vSAN 8 Update 1, предназначенного для создания высокопроизводительных отказоустойчивых хранилищ для виртуальных машин, а также об улучшениях подсистемы хранения Core Storage в обеих платформах.

Недавно компания VMware также выпустила большую техническую статью "What's New with vSphere 8 Core Storage", в которой детально рассмотрены все основные новые функции хранилищ, с которыми работают платформы vSphere и vSAN. Мы решили перевести ее с помощью ChatGPT и дальше немного поправить вручную. Давайте посмотрим, что из этого вышло :)

Итак что нового в части Core Storage платформы vSphere 8 Update 1

Одно из главных улучшений - это новая система управления сертификатами. Она упрощает возможность регистрации нескольких vCenter в одном VASA-провайдере. Это положит основу для некоторых будущих возможностей, таких как vVols vMSC. Такж есть и функции, которые касаются масштабируемости и производительности. Поскольку vVols могут масштабироваться гораздо лучше, чем традиционное хранилище, VMware улучшила подсистему хранения, чтобы тома vVols работали на больших масштабах.

1. Развертывание нескольких vCenter для VASA-провайдера без использования самоподписанных сертификатов

Новая спецификация VASA 5 была разработана для улучшения управления сертификатами vVols, что позволяет использовать самоподписанные сертификаты для многовендорных развертываний vCenter. Это решение также решает проблему управления сертификатами в случае, когда независимые развертывания vCenter, работающие с различными механизмами управления сертификатами, работают вместе. Например, один vCenter может использовать сторонний CA, а другой vCenter может использовать сертификат, подписанный VMCA. Такой тип развертывания может быть использован для общего развертывания VASA-провайдера. Эта новая возможность использует механизм Server Name Indication (SNI).

SNI - это расширение протокола Transport Layer Security (TLS), с помощью которого клиент указывает, какое имя хоста он пытается использовать в начале процесса handshake. Это позволяет серверу показывать несколько сертификатов на одном IP-адресе и TCP-порту. Следовательно, это позволяет обслуживать несколько безопасных (HTTPS) веб-сайтов (или других служб через TLS) с одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это является концептуальным эквивалентом виртуального хостинга на основе имени HTTP/1.1, но только для HTTPS. Также теперь прокси может перенаправлять трафик клиентов на правильный сервер во время хэндшейка TLS/SSL.

2. Новая спецификация vVols VASA 5.0 и некоторые детали функций

Некоторые новые функции, добавленные в vSphere 8 U1:

• Изоляция контейнеров - работает по-разному для поставщиков VASA от различных производителей. Она позволяет выполнять настройку политики контроля доступа на уровне каждого vCenter, а также дает возможность перемещения контейнеров между выбранными vCenter. Это дает лучшую изоляцию на уровне контейнеров, а VASA Provider может управлять правами доступа для контейнера на уровне каждого vCenter.
• Аптайм - поддержка оповещений об изменении сертификата в рамках рабочего процесса VASA 5.0, который позволяет обновлять сертификат VMCA в системах с несколькими vCenter. Недействительный или истекший сертификат вызывает простой, также возможно возникновение простоя при попытке регистрации нескольких vCenter с одним VASA Provider. В конфигурации с несколькими vCenter сертификаты теперь можно обновлять без простоя.
• Улучшенная безопасность для общих сред - эта функция работает по-разному для поставщиков VASA от производителей. Все операции могут быть аутентифицированы в контексте vCenter, и каждый vCenter имеет свой список контроля доступа (ACL). Теперь нет самоподписанных сертификатов в доверенном хранилище. VASA Provider может использоваться в облачной среде, и для этого также есть доступная роль в VASA 5.0.
• Обратная совместимость - сервер ESXi, который поддерживает VASA 5.0, может решать проблемы с самоподписанными сертификатами и простоями, возникающими в случае проблем. VASA 5.0 остается обратно совместимым и дает возможность контролировать обновление в соответствии с требованиями безопасности. VASA 5.0 может сосуществовать с более ранними версиями, если производитель поддерживает эту опцию.
• Гетерогенная конфигурация сертификатов - работает по-разному для поставщиков VASA от производителей. Теперь используется только подписанный сертификат VMCA, дополнительный CA не требуется. Это позволяет изолировать доверенный домен vSphere. VASA 5.0 позволяет использовать разные конфигурации для каждого vCenter (например, Self-Managed 3rd Party CA Signed Certificate и VMCA managed Certificate).
• Не необходимости вмешательства администратора - поддержка многократного развертывания vCenter с использованием VMCA, которая не требует от пользователя установки и управления сертификатами для VP. Служба SMS будет отвечать за предоставление сертификатов. Теперь это работает в режиме Plug and Play с автоматической предоставлением сертификатов, без вмешательства пользователя, при этом не требуется никаких ручных действий для использования VASA Provider с любым vCenter.
• Комплаенс безопасности - отсутствие самоподписанных сертификатов в доверенных корневых центрах сертификации позволяет решить проблемы соответствия требованиям безопасности. Не-СА сертификаты больше не являются частью хранилища доверенных сертификатов vSphere. VASA 5.0 требует от VASA Provider использовать сертификат, подписанный СА для связи с VASA.

3. Перенос Sidecar vVols в config-vvol вместо другого объекта vVol

Sidecars vVols работали как объекты vVol, что приводило к накладным расходам на операции VASA, такие как bind/unbind. Решения, такие как First Class Disks (FCD), создают большое количество маленьких sidecars, что может ухудшить производительность vVols. Кроме того, поскольку может быть создано множество sidecars, это может учитываться в общем количестве объектов vVol, поддерживаемых на массиве хранения. Чтобы улучшить производительность и масштабируемость, теперь они обрабатываются как файлы на томе config-vvol, где могут выполняться обычные операции с файлами. Не забывайте, что в vSphere 8 был обновлен способ байндига config-vvol. В результате, с новым механизмом config-vvol уменьшается число операций и задержки, что улучшает производительность и масштабируемость.

Для этой функциональности в этом релизе есть несколько ограничений при создании ВМ. Старые виртуальные машины могут работать в новом формате на обновленных до U1 хостах, но сам новый формат не будет работать на старых ESXi. То есть новые созданные ВМ и виртуальные диски не будут поддерживаться на хостах ниже версии ESXi 8 U1.

5. Улучшения Config-vvol, поддержка VMFS6 config-vvol с SCSI vVols (вместо VMFS5)

Ранее Config-vvol, который выступает в качестве каталога для хранилища данных vVols и содержимого VM home, был ограничен размером 4 ГБ. Это не давало возможности использования папок с хранилищем данных vVols в качестве репозиториев ВМ и других объектов. Для преодоления этого ограничения Config-vvol теперь создается как тонкий объект объемом 255 ГБ. Кроме того, вместо VMFS-5 для этих объектов будет использоваться формат VMFS-6. Это позволит размещать файлы sidecar, другие файлы VM и библиотеки контента в Config-vvol.

На изображении ниже показаны Config-vvol разных размеров. Для машины Win10-5 Config-vvol использует исходный формат 4 ГБ, а ВМ Win10-vVol-8u1 использует новый формат Config-vvol объемом 255 ГБ.

6. Добавлена поддержка NVMe-TCP для vVols

В vSphere 8 была добавлена поддержка NVMe-FC для vVols. В vSphere 8 U1 также расширена поддержка NVMe-TCP, что обеспечивает совместное использование NVMeoF и vVols. См. статью vVols with NVMe - A Perfect Match | VMware.

7. Улучшения NVMeoF, PSA, HPP

Инфраструктура поддержки NVMe end-to-end:

Расширение возможностей NVMe дает возможность поддержки полного стека NVMe без какой-либо трансляции команд SCSI в NVMe на любом уровне ESXi. Еще одной важной задачей при поддержке end-to-end NVMe является возможность контроля multipath-плагинов сторонних производителей для управления массивами NVMe.

Теперь с поддержкой GOS протокол NVMe может использоваться для всего пути - от GOS до конечного таргета.

Важным аспектом реализации VMware трансляции хранилищ виртуальных машин является поддержка полной обратной совместимости. VMware реализовала такой механизм, что при любом сочетании виртуальных машин, использующих SCSI или контроллер vNVMe, и целевого устройства, являющегося SCSI или NVMe, можно транслировать путь в стеке хранения. Это дизайн, который позволяет клиентам переходить между SCSI- и NVMe-хранилищами без необходимости изменения контроллера хранилищ для виртуальной машины. Аналогично, если виртуальная машина имеет контроллер SCSI или vNVMe, он будет работать как на SCSI-, так и на NVMeoF-хранилищах.

Упрощенная диаграмма стека хранения выглядит так:

Для получения дополнительной информации о NVMeoF для vSphere, обратитесь к странице ресурсов NVMeoF.

8. Увеличение максимального количества путей для пространств имен NVMe-oF с 8 до 32

Увеличение количества путей улучшает масштабирование в окружениях с несколькими путями к пространствам имен NVMe. Это необходимо в случаях, когда хосты имеют несколько портов и модуль имеет несколько нод, а также несколько портов на одной ноде.

9. Увеличение максимального количества кластеров WSFC на один хост ESXi с 3 до 16

Это позволяет уменьшить количество лицензий Microsoft WSFC, необходимых для увеличения количества кластеров, которые могут работать на одном хосте.

Для получения дополнительной информации о работе Microsoft WSFC на vSphere можно обратиться к следующим ресурсам:

• О настройке кластеров отказоустойчивости Windows Server на VMware vSphere
• Начало работы с WSFC на VMware vSphere
• Требования к оборудованию и программному обеспечению для WSFC на vSphere
• Кластер отказоустойчивости Microsoft Windows Server (WSFC) с общими дисками на VMware vSphere 8.x: Рекомендации по поддерживаемым конфигурациям (89327)
• Кластер отказоустойчивости Microsoft Windows Server (WSFC) с общими дисками на VMware vSphere 7.x: Рекомендации по поддерживаемым конфигурациям (79616)

10. Улучшения VMFS - расширенная поддержка XCOPY для копирования содержимого датасторов между различными массивами

ESXi теперь поддерживает расширенные функции XCOPY, что оптимизирует копирование данных между датасторами разных массивов. Это поможет клиентам передать обработку рабочих нагрузок на сторону хранилища. Функция уже доступна в vSphere 8 U1, но по факту миграция данных между массивами должна поддерживаться на стороне хранилища.

11. Реализация NFSv3 vmkPortBinding

Данная функция позволяет привязать соединение NFS для тома к конкретному vmkernel. Это помогает обеспечить безопасность, направляя трафик NFS по выделенной подсети/VLAN, и гарантирует, что трафик NFS не будет использовать mgmt-интерфейс или другие интерфейсы vmkernel.

Предыдущие монтирования NFS не содержат этих значений, хранящихся в config store. Во время обновления, при чтении конфигурации из конфигурационного хранилища, значения vmknic и bindTovmnic, если они есть, будут считаны. Поэтому обновления с предыдущих версий не будут содержать этих значений, так как они являются необязательными.

12. Улучшения VM Swap

Здесь появились следующие улучшения:

• Увеличена производительность включения/выключения ВМ
• Увеличена производительность vMotion

Изменения в способе создания/удаления Swap-файлов для томов vVols помогли улучшить производительность включения/выключения, а также производительность vMotion и svMotion.

13. Улучшения Config vVol и сохранение привязки

Здесь были сделаны следующие доработки:

• Уменьшено время запроса при получении информации о ВМ
• Добавлено кэширование атрибутов vVol - размер, имя и прочих

Конфигурационный vVol - это место, где хранятся домашние файлы виртуальной машины (vmx, nvram, logs и т. д.) и к нему обычно обращаются только при загрузке или изменении настроек виртуальной машины.

Ранее использовалась так называемая "ленивая отмена связи" (lazy unbind), и происходил unbind конфигурационного vVol, когда он не использовался. В некоторых случаях приложения все же периодически обращались к конфигурационному vVol, что требовало новой операции привязки. Теперь эта связь сохраняется, что уменьшает задержку при доступе к домашним данным виртуальной машины.

14. Поддержка NVMeoF для vVols

vVols были основным направлением развития функциональности хранилищ VMware в последние несколько версий, и для vSphere 8.0 это не исключение. Самое большое обновление в ядре хранения vSphere 8.0 - добавление поддержки vVols в NVMeoF. Изначально поддерживается только FC, но со временем будут работать и другие протоколы, провалидированные и поддерживаемые с помощью vSphere NVMeoF. Теперь есть новая спецификация vVols и VASA/VC-фреймворка - VASA 4.0/vVols 3.0.

Причина добавления поддержки vVols в NVMeoF в том, что многие производители массивов, а также отрасль в целом, переходят на использование или, по крайней мере, добавление поддержки NVMeoF для повышения производительности и пропускной способности. Вследствие этого VMware гарантирует, что технология vVols остается поддерживаемой для последних моделей хранилищ.

Еще одним преимуществом NVMeoF vVols является настройка. При развертывании после регистрации VASA фоновая установка завершается автоматически, вам нужно только создать датастор. Виртуальные эндпоинты (vPE) и соединения управляются со стороны VASA, что упрощает настройку.

Некоторые технические детали этой реализации:

• ANA Group (Асимметричный доступ к пространству имен)

С NVMeoF реализация vVols немного отличается. С традиционными SCSI vVols хранилищами контейнер является логической группировкой самих объектов vVol. С NVMeoF это варьируется в зависимости от того, как поставщик массива реализует функциональность. В общем и целом, на хранилище группа ANA является группировкой пространств имен vVol. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Пространства имен выделяются и активны только по запросу BIND к провайдеру VASA (VP). Пространства имен также добавляются в группу ANA при запросе BIND к VP. Пространство имен остается выделенным/активным до тех пор, пока последний хост не отвяжет vVol.

• vPE (virtual Protocol Endpoint)

Для традиционных vVols на базе SCSI, protocol endpoint (PE) - это физический LUN или том на массиве, который отображается в появляется в разделе устройств хранения на хостах. С NVMeoF больше нет физического PE, PE теперь является логическим объектом, представлением группы ANA, в которой находятся vVols. Фактически, до тех пор, пока ВМ не запущена, vPE не существует. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Как только ВМ запущена, создается vPE, чтобы хост мог получить доступ к vVols в группе ANA. На диаграмме ниже вы можете увидеть, что vPE указывает на группу ANA на массиве.

• NS (пространство имен, эквивалент LUN в NVMe)

Каждый тип vVol (Config, Swap, Data, Mem), созданный и использующийся машиной, создает NS, который находится в группе ANA. Это соотношение 1:1 между vVol и NS позволяет вендорам оборудования легко масштабировать объекты vVols. Обычно поставщики поддерживают тысячи, а иногда и сотни тысяч NS. Ограничения NS будут зависеть от модели массива.

На диаграмме вы можете увидеть, что сама виртуальная машина является NS, это будет Config vVol, а диск - это другой NS, Data vVol.

Вы можете узнать больше о технических деталях NVMe-FC и vVols в этой статье блога: "vVols with NVMe - A Perfect Match | VMware".

15. Улучшения NVMeoF

• Поддержка 256 пространств имен и 2K путей с NVMe-TCP и NVMe-FC

NVMeoF продолжает набирать популярность по очевидным причинам - более высокая производительность и пропускная способность по сравнению с традиционным подключением SCSI или NFS. Многие производители хранилищ также переходят на NVMe-массивы и использование SCSI для доступа к NVMe флэш-накопителям является узким местом и потенциалом для улучшений.

Продолжая работать на этим, VMware увеличила поддерживаемое количество пространств имен и путей как для NVMe-FC, так и для TCP.

• Расширение reservations для устройств NVMe

Добавлена поддержка команд reservations NVMe для использования таких решений, как WSFC. Это позволит клиентам использовать возможности кластеризованных дисков VMDK средствами Microsoft WSFC с хранилищами данных NVMeoF. Пока поддерживается только протокол FC.

• Поддержка автообнаружения для NVMe Discovery Service на ESXi

Расширенная поддержка NVMe-oF в ESXi позволяет динамически обнаруживать совместимые со стандартом службы NVMe Discovery Service. ESXi использует службу mDNS/DNS-SD для получения информации, такой как IP-адрес и номер порта активных служб обнаружения NVMe-oF в сети.

Также ESXi отправляет многоадресный DNS-запрос (mDNS), запрашивая информацию от сущностей, предоставляющих службу обнаружения DNS-SD. Если такая сущность активна в сети (на которую был отправлен запрос), она отправит (одноадресный) ответ на хост с запрошенной информацией - IP-адрес и номер порта, где работает служба.

16. Улучшение очистки дискового пространства с помощью Unmap

• Снижение минимальной скорости очистки до 10 МБ/с

Начиная с vSphere 6.7, была добавлена функция настройки скорости очистки (Unmap) на уровне хранилища данных. С помощью этого улучшения клиенты могут изменять скорость очистки на базе рекомендаций поставщика их массива. Более высокая скорость очистки позволяла многим пользователям быстро вернуть неиспользуемое дисковое пространство. Однако иногда даже при минимальной скорости очистки в 25 МБ/с она может быть слишком высокой и привести к проблемам при одновременной отправке команд Unmap несколькими хостами. Эти проблемы могут усугубляться при увеличении числа хостов на один датастор.

Пример возможной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с

Чтобы помочь клиентам в ситуациях, когда скорость очистки 25 МБ/с может приводить к проблемам, VMware снизила минимальную скорость до 10 МБ/с и сделала ее настраиваемой на уровне датасторов:

При необходимости вы также можете полностью отключить рекламацию пространства для заданного datastore.

• Очередь планирования отдельных команд Unmap

Отдельная очередь планирования команд Unmap позволяет выделить высокоприоритетные операции ввода-вывода метаданных VMFS и обслуживать их из отдельных очередей планирования, чтобы избежать задержки их исполнения из-за других команд Unmap.

17. Контейнерное хранилище CNS/CSI

Теперь вы можете выбрать политику Thin provisioning (EZT, LZT) через SPBM для CNS/Tanzu.

Цель этого - добавить возможность политик SPBM для механизма создания/изменения правил политик хранения, которые используются для параметров выделения томов. Это также облегчает проверку соответствия правил выделения томов в политиках хранения для SPBM.

• Операции, поддерживаемые для виртуальных дисков: создание, реконфигурация, клонирование и перемещение.
• Операции, поддерживаемые для FCD: создание, обновление политики хранения, клонирование и перемещение.

18. Улучшения NFS

Инженеры VMware всегда работают над улучшением надежности доступа к хранилищам. В vSphere 8 были добавлены следующие улучшения NFS, повышающие надежность:

• Повторные попытки монтирования NFS при сбое
• Валидация монтирования NFS

Ну как вам работа ChatGPT с правками человека? Читабельно? Напишите в комментариях!

В марте компания VMware анонсировала скорую доступность первого пакета обновлений своей флагманской платформы виртуализации VMware vSphere 8.0 Update 1. Напомним, что прошлая версия VMware vSphere 8.0 была анонсирована на конференции VMware Explore 2022 в августе прошлого года.

Давайте посмотрим, что нового появилось в vSphere 8.0 U1:

1. Полная поддержка vSphere Configuration Profiles

В vSphere 8.0 эта функциональность впервые появилась и работала в режиме технологического превью, а в Update 1 она полностью вышла в продакшен. Эта возможность представляет собой новое поколение инструментов для управления конфигурациями кластеров и заменяет предыдущую функцию Host Profiles. Ее особенности:

• Установка желаемой конфигурации на уровне кластера в форме JSON-документа
• Проверка хостов на соответствие желаемой конфигурации
• При выявлении несоответствий - перенастройка хостов на заданный уровень конфигурации

В vSphere 8 Update 1 возможности Configuration Profiles поддерживают настройку распределенных коммутаторов vSphere Distributed Switch, которая не была доступна в режиме технологического превью. Однако, окружения, использующие VMware NSX, все еще не поддерживаются.

Существующие кластеры можно перевести под управление Configuration Profiles. Если для кластера есть привязанный профиль Host Profile, то вы увидите предупреждение об удалении профиля, когда кластер будет переведен в Configuration Profiles. Как только переход будет закончен, Host Profiles уже нельзя будет привязать к кластеру и хостам.

Если кластер все еще использует управление жизненным циклом на базе бейзлайнов, то сначала кластер нужно перевести в режим управления image-based:

vSphere Configuration Profiles могут быть активированы при создании нового кластера. Это требует, чтобы кластер управлялся на основе единого определения образа. После создания кластера доступна кастомизация конфигурации. Более подробно о возможностях Configuration Profiles можно почитать здесь.

2. vSphere Lifecycle Manager для отдельных хостов

В vSphere 8 появилась возможность управлять через vSphere Lifecycle Manager отдельными хостами ESXi под управлением vCenter посредством vSphere API. В Update 1 теперь есть полная поддержка vSphere Client для этого процесса - создать образ, проверить и привести в соответствие, а также другие функции.

Все, что вы ожидаете от vSphere Lifecycle Manager для взаимодействия с кластером vSphere, вы можете делать и для отдельных хостов, включая стейджинг и функции ESXi Quick Boot.

Также вы можете определить кастомные image depots для отдельных хостов - это полезно, когда у вас есть хост, который находится на уровне edge и должен использовать depot, размещенный совместно с хостом ESXi, во избежание проблем с настройкой конфигурации при плохом соединении удаленных друг от друга хостов ESXi и vCenter.

3. Различные GPU-нагрузки хоста на базе одной видеокарты

В предыдущих версиях vSphere все рабочие нагрузки NVIDIA vGPU должны были использовать тот же самый тип профиля vGPU и размер памяти vGPU. В vSphere 8 U1 модули NVIDIA vGPU могут быть назначены для различных типов профилей. Однако, размер памяти для них должен быть, по-прежнему, одинаковым. Например, на картинке ниже мы видим 3 виртуальных машины, каждая с разным профилем (B,C и Q) и размером памяти 8 ГБ. Это позволяет более эффективно разделять ресурсы между нагрузками разных видов.

NVIDIA позволяет создавать следующие типы профилей vGPU:

• Profile type A - для потоково доставляемых приложений или для решений на базе сессий
• Profile type B - для VDI-приложений
• Profile type C - для приложений, требовательных к вычислительным ресурсам (например, machine learning)
• Profile type Q - для приложений, требовательных к графике

4. Службы Supervisor Services для vSphere Distributed Switch

В vSphere 8 Update 1, в дополнение к VM Service, службы Supervisor Services теперь доступны при использовании сетевого стека vSphere Distributed Switch.

Supervisor Services - это сертифицированные в vSphere операторы Kubernetes, которые реализуют компоненты Infrastructure-as-a-Service, тесно интегрированные со службами независимых разработчиков ПО. Вы можете установить и управлять Supervisor Services в окружении vSphere with Tanzu, чтобы сделать их доступными для использования рабочими нагрузками Kubernetes. Когда Supervisor Services установлены на Supervisors, инженеры DevOps могут использовать API для создания инстансов на Supervisors в рамках пользовательских пространств имен.

Более подробно об этом рассказано тут.

5. Функция Bring Your Own Image для VM Service

Возможность VM Service была доработана, чтобы поддерживать образы ВМ, созданные пользователями. Теперь администраторы могут собирать собственные пайплайны сборки образов с поддержкой CloudInit и vAppConfig.

Администраторы могут добавить эти новые шаблоны ВМ в Content library, чтобы они стали доступны команде DevOps. А сами DevOps создают спецификацию cloud-config, которая настроит ВМ при первой загрузке. Команда DevOps отправляет спецификацию ВМ вместе cloud-config для создания и настройки ВМ.

Более подробно об этом можно почитать тут и тут.

6. Консоли виртуальных машин для DevOps

DevOps могут теперь получать простой доступ к виртуальным машинам, которые они развернули, с использованием kubectl.

В этом случае создается уникальная ссылка, по которой можно получить доступ к консоли ВМ, и которая не требует настройки разрешений через vSphere Client. Веб-консоль дает по этому URL доступ пользователю к консоли машины в течение двух минут. В этом случае нужен доступ к Supervisor Control Plane по порту 443.

Веб-консоль ВМ дает возможности самостоятельной отладки и траблшутинга даже для тех ВМ, у которых может не быть доступа к сети и настроенного SSH.

7. Интегрированный плагин Skyline Health Diagnostics

Теперь развертывание и управление VMware Skyline Health Diagnostics упростилось за счет рабочего процесса, встроенного в vSphere Client, который дает возможность просто развернуть виртуальный модуль и зарегистрировать его в vCenter.

Skyline Health Diagnostics позволяет вам:

• Диагностировать и исправлять различные типы отказов в инфраструктуре
• Выполнять проверку состояния компонентов (health checks)
• Понимать применимость VMware Security Advisories и связанных элементов
• Обнаруживать проблемы, которые влияют на апдейты и апгрейды продукта

Утилита использует логи, конфигурационную информацию и другие источники для обнаружения проблем и предоставления рекомендаций в форме ссылок на статьи KB или шагов по исправлению ситуации.

8. Улучшенные метрики vSphere Green Metrics

В vSphere 8.0 появились метрики, которые отображают потребление энергии виртуальными машинами с точки зрения энергоэффективности виртуального датацентра. В vSphere 8.0 Update 1 теперь можно отслеживать их на уровне отдельных ВМ. Они берут во внимание объем ресурсов ВМ, чтобы дать пользователю более точную информацию об энергоэффективности на уровне отдельных нагрузок. Разработчики также могут получать их через API, а владельцы приложений могут получать агрегированное представление этих данных.

Метрика Static Power - это смоделированное потребление мощности простаивающих ресурсов ВМ, как если бы она был хостом bare-metal с такими же аппаратными параметрами процессора и памяти. Static Power оценивает затраты на поддержание таких хостов во включенном состоянии. Ну а Usage - это реально измеренное потребление мощности ВМ в активном режиме использования CPU и памяти, которые запрашиваются через интерфейс (IPMI - Intelligent Platform Management Interface).

9. Функция Okta Identity Federation для vCenter

vSphere 8 Update 1 поддерживает управление идентификациями и многофакторной аутентификацией в облаке, для чего на старте реализована поддержка Okta.

Использование Federated identity подразумевает, что vSphere не видит пользовательских учетных данных, что увеличивает безопасность. Это работает по аналогии со сторонними движками аутентификации в вебе, к которым пользователи уже привыкли (например, логин через Google).

10. Функции ESXi Quick Boot для защищенных систем

vSphere начала поддерживать Quick Boot еще с версии vSphere 6.7. Теперь хосты с поддержкой TPM 2.0 проходят через безопасный процесс загрузки и аттестации, что позволяет убедиться в неизменности хоста - а это надежный способ предотвратить атаки malware. Quick Boot теперь стал полноценно совместимым процессом в vSphere 8 Update 1.

11. Поддержка vSphere Fault Tolerance с устройствами vTPM

Функции непрерывной доступности VMware vSphere Fault Tolerance (FT) позволяют подхватить исполнение рабочей нагрузки на резервном хосте без простоя в случае проблем основной ВМ. Теперь эта функция поддерживает ВМ, настроенные с устройствами vTPM.

Модели Virtual TPM - это важный компонент инфраструктуры, используемый такими решениями, как Microsoft Device Guard, Credential Guard, Virtualization-Based Security, Secure Boot & OS attestation, а также многими другими. Это, зачастую, и часть регуляторных требований комплаенса.

12. Поддержка Nvidia NVSwitch

В рамках партнерства с NVIDIA, VMware продолжает расширять поддержку продуктового портфеля этого вендора.

Эта технология используется в high-performance computing (HPC) и для AI-приложений (deep learning, научное моделирование и анализ больших данных), что требует работы модулей GPU совместно в параллельном режиме. В современном серверном оборудовании различные приложения ограничены параметрами шины. Чтобы решить эту проблему, NVIDIA создала специальный коммутатор NVSwitch, который позволяет до 8 GPU взаимодействовать на максимальной скорости.

Вот нюансы технологий NVLink и NVSwitch:

• NVLink - это бэкенд протокол для коммутаторов NVSwitch. NVLink создает мост для соединений точка-точка и может быть использован для линковки от 2 до 4 GPU на очень высокой скорости.
• NVSwitch требует, чтобы более 4 GPU были соединены, а также использует поддержку vSphere 8U1 NVSwitch для формирования разделов из 2, 4 и 8 GPU для работы виртуальных машин.
• NVLink использует архитектуру Hopper, что предполагает создания пары GPU, которые передают до 450 GB/s (то есть общая скорость до 900 GB/s).

Для сравнения архитектура Gen5 x16 может передавать на скорости до 64 GB/s, то есть NVLink и NVSwitch дают очень существенный прирост в скорости.

13. Функции VM DirectPath I/O Hot-Plug для NVMe

В прошлых релизах добавление или удаление устройств VM DirectPath IO требовало нахождения ВМ в выключенном состоянии. Теперь же в vSphere 8 Update 1 появилась поддержка горячего добавления и удаления устройств NVMe через vSphere API.

На этом пока все, в следующих статьях мы расскажем об улучшениях Core Storage в vSphere 8 Update 1.

Многие администраторы сталкиваются с необходимостью обновления пакета VMware Tools в большом количестве виртуальных машин, работающих на серверах ESXi платформы VMware vSphere.

Общие сведения об обновлении VMware Tools

На данный момент можно использовать один из трех способов массового VMware Tools в большой инфраструктуре:

• Применение средства VMware vSphere Lifecycle Manager (ранее его функционал был частью VMware Update Manager)
• Написание сценариев для фреймворка VMware vSphere PowerCLI
• Использование сторонних утилит для обновления тулзов

В отличие от версий аппаратной обеспечения (VM Hardware), компания VMware рекомендует всегда использовать последнюю версию пакета VMware Tools, для которого есть матрицы совместимости с различными версиями хостов ESXi. Посмотреть их можно по этой ссылке.

Например, мы видим, что VMware Tools 2016 года все еще можно использовать в ВМ на ESXi 7.0 U3. Также виртуальная машина на сервере VMware ESXi 5.5 может иметь текущую версию VMware Tools (сейчас это 12.1.5).

Напомним, что VMware Tools - это не только часть дистрибутива vSphere, но и отдельный продукт, который можно скачать с портала Customer Connect.

Есть несколько вариантов по загрузке этого пакета:

• Бандл для общего репозитория Locker (например, VMware-Tools-windows-12.1.5-20735119.zip) - он используется для создания локального или общего репозитория с нужной версией VMware Tools.
• Установщик в гостевой ОС, который можно запустить в ней как исполняемый файл (VMware-tools-12.1.5-20735119-x86_64.exe.zip).
• Пакеты для GuestStore (gueststore-vmtools-12.1.5-20735119-20735876.zip) - это новая возможность, которая появилась в vSphere 7.0 U2. GuestStore сделан не для обновления VMware Tools, но может использоваться для этой цели (это тема для отдельной статьи).
• Офлайн VIB-пакет с тулзами (VMware-Tools-12.1.5-core-offline-depot-ESXi-all-20735119.zip) - он используется как Baseline для обновления VMware Tools на хостах.

Исторически пакет VMware Tools, в основном, выпускался для Windows и Linux. Есть также версии этого пакета и для FreeBSD, Solaris и MacOS. Здесь есть следующие нюансы:

• Тулзы версии 10.3.5 for Linux были заморожены в разработке, вместо них теперь есть пакет open-vm-tools.
• Начиная с версии VMware Tools 10.2.0, инсталляция на базе Perl-скриптов для FreeBSD больше не поддерживается. В этом случае также надо использовать open-vm-tools.
• Последняя версия тулзов для гостевых ОС Solaris - это 10.3.10.

Как мы увидим дальше, очень важно знать, какая версия VMware Tools размещена локально на хосте ESXi после его установки. Эта версия может быть использована для проверки актуальных пакетов в виртуальных машинах. Для быстрой проверки текущей версии пакета на хосте можно использовать следующую команду:

esxcli software component get | grep VMware-VM-Tools -B 1 -A 14

Если вы хотите использовать для этого PowerCLI, то можно выполнить следующий сценарий:

	
$Result = @()

foreach ($ViHost in (Get-VMhost)) {

    $esxcli = $ViHost | Get-esxcli -V2

    $ToolsVersion = ($esxcli.software.component.get.Invoke() | Where-Object {$_.name -eq "VMware-VM-Tools"}).Version

    $Result += [PSCustomObject] @{

        HostName = $ViHost.Name;

        ToolsVersion = $ToolsVersion}

}

$Result

Способы обновления VMware Tools

Итак, рассмотрим обновление VMware Tools одним из двух способов:

• Обновление VMware Tools как отдельного пакета ПО

В этом случае для нужно версии тулзов можно использовать любое средство, например Microsoft System Center, которое предназначено для массового развертывания программ. Также вы можете использовать любые скрипты и другие средства в режиме тихой установки (silent install).

• Обновление VMware Tools посредством функционала vSphere

При развертывании и апгрейде хостов ESXi на них помещаются соответствующие версии VMware Tools (чтобы узнать список версий, загляните сюда). По умолчанию пакеты помещаются в папку /productLocker на хосте ESXi - это symbolic link, то есть просто указатель на настроенную папку. Чтобы узнать, какая версия VMware Tools является текущей, сервер vCenter сравнивает установленную версию тулзов в ВМ с версией, которая хранится в разделе /productLocker. Если актуальная версия в гостевой ОС меньше хранящейся на хосте, то в vSphere Client вы увидите соответствующее предупреждение:

Далее вам нужно выполнить процедуру, состоящую из двух основных шагов:

• Настраиваем хост ESXi для использования определенной версии VMware Tools
• Автоматизируем процесс обновления тулзов в гостевых ОС виртуальных машин

Шаг 1 - Настройка хоста ESXi для использования определенной версии VMware Tools

Надо сказать, что не рекомендуется вручную обновлять содержимое папки /productLocker, так как это не поддерживаемый официально процесс, и при апгрейде хоста вы можете получить более старую версию пакета. Также вы можете использовать конкретную версию VMware Tools для всех ВМ (например, ту, что содержит исправление конкретного бага).

Это рекомендуемый способ обновления пакета VMware Tools, здесь может быть использован один из двух пакетов обновления хостов в кластере:

• Baseline based
• Single image

Если вы обновляете кластер, используя базовые уровни (baselines), вы можете создать кастомный образ, который включает желаемые версии VMware Tools, либо вы можете развернуть тулзы с использованием кастомного бейзлайна.

Давайте посмотрим на обновление с использованием метода Baseline:

• Просто скачиваем VMware Tools Offline VIB bundle

• Загружаем бандл на vSphere Lifecycle Manager (либо VIB-пакет может быть загружен этим продуктом автоматически)
• Создаем новый базовый уровень, содержащий только пакет VMware Tools VIB
• Привязываем бейзлайн к тому уровню иерархии, для которого будут выполняться апдейты, а также запускаем проверку комплаенса на хостах
• Выполняем функцию Remediate для накатывания VMware Tools для ВМ на хостах ESXi

После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.

Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.

Теперь посмотрим на процесс обновления VMware Tools методом Single Image:

Это более современный метод обновления тулзов на хостах в кластере. Вам нужно выбрать нужную версию VMware Tools как дополнительного компонента при определении образа.

В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.

Создаем общий репозиторий для нужной версии VMware Tools

Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.

Как это выглядит по шагам:

1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:

cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name

2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:

rm -rf /vmfs/volumes/datastore/vmtools-repository-name/*

3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:

На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.

4. Устанавливаем правильные разрешения:

chmod -R 700 /vmfs/volumes/datastore/vmtools-repository-name/*

5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.

Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:

• Для вывода текущей директории Locker выполняем следующий командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value

• Для изменения директории выполняем такой командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Set-AdvancedSetting -Confirm:$false -Value "/vmfs/volumes/datastore/vmtools-repository-name/"

Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.

6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.

Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин

Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.

Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsVersion}}

Это не самая удобная нотация, но она соответствует той, что мы видим на странице VM Summary на сервере vCenter. Для получения параметров этой команды используйте маппинг-файл версий.

4 способа автоматизации обновления VMware Tools в гостевой ОС:

1. Обновляем VMware Tools немедленно или ставим запланированную задачу через vCenter

Через интерфейс не всегда удобно работать с массовым обновлением, но в данном случае это можно сделать с помощью отфильтрованного списка ВМ и установки настроек по срабатыванию действий с объектами.

vSphere Lifecycle Manager имеет довольно мощный функционал в этом плане. Процесс обновления можно запланировать на базе состояния питания ВМ. Также можно задать опции предварительного создания снапшота ВМ.

Выбираем нужный кластер, идем на вкладку Updates и выбираем VMware Tools. Фильтруем нужные нам ВМ или выбираем все, далее кликаем Upgrade to match host. В следующих окнах у вас будет множество опций для создания запланированной задачи:

Вы можете не только настроить создания снапшота перед апдейтом, но и задать число часов, по истечении которых снапшот будет удален. Также в состав снапшота может входить и состояние оперативной памяти.

Также помните, что массовое удаление снапшотов в одно время может создать очень большую нагрузку на хранилище. Поэтому лучше снапшоты использовать только для самых критичных ВМ, которые должны сразу оказаться доступными в случае каких-либо проблем.

Дефолтные настройки для этих параметров вы можете установить здесь: Menu -> Lifecycle Manager -> Settings -> VMs:

2. Мгновенное обновление VMware Tools через vSphere PowerCLI

Для обновления тулзов на выбранных хостах (или всех) используется командлет Update-Tools. Он инициирует процесс обновления пакета изнутри гостевой ОС. По умолчанию Update-Tools ждет завершения обновления, после чего инициируется процесс перезагрузки ВМ. Это поведение можно изменить, используя параметры NoReboot и RunAsync.

Следующая команда начинает процесс обновления в виртуальной машине Win2019-01 в рамках задачи:

Get-VM Win2019-01 | Update-Tools –RunAsync

Чтобы посмотреть статус выполняемых задач, используйте команду Get-Task:

Так как это команда PowerShell - ее также можно добавить в запланированные задачи.

3. Обновление VMware Tools при следующей загрузке ВМ в интерфейсе vSphere Client

В рамках окна обслуживания виртуальные машины обычно можно перезагружать. Его, как раз, можно использовать и для обновления VMware Tools. Для этого надо настроить ВМ для проверки версии тулзов при загрузке. Если установленная версия меньше необходимой (по ссылке в /productLocker), то начинается процесс апдейта.

Для изменения политики обновлений, выберите нужный кластер и перейдите на вкладку Updates, где выберите VMware Tools. Там можно фильтровать список ВМ:

После того, как вы выберете машины, можно задать политику автообновления для них:

4. Обновление тулзов при следующей загрузке с использованием vSphere PowerCLI

Сначала посмотрим, текущую конфигурацию ВМ через PowerCLI:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsUpgradePolicy}}

Здесь могут быть следующие политики - manual и UpgradeAtPowerCycle. Нам нужно использовать вторую. Итак, сначала определяем переменные:

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"

Далее применяем эти политики к виртуальным машинам:

$VMs = Get-VM -Name "Win*"
$VMs.ExtensionData.ReconfigVM_Task($vmConfigSpec)

Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.

Совсем недавно вышел новый релиз Vinchin Backup & Recovery V7.0, который уже доступен для скачивания. Сегодня мы поговорим о продуктах и технологиях компании Vinchin для резервного копирования виртуальных машин и обеспечения защиты данных виртуального датацентра. В первой части мы расскажем о кратком обзоре вебинара Vinchin Backup & Recovery V7.0, который прошел 1 марта...

Публикуем пятую часть нашего большого рассказа о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.

• В первой части мы рассказали о том, что нового появилось в продукте в части прямого резервного копирования в объектные хранилища, неизменяемых бэкапов и безопасности.
• Во второй мы говорили о новых возможностях в плане поддержки гибридных облаков, платформы и движка, управления данными резервных копий и инфраструктуры бэкапов.
• В третьей - о новых функциях резервного копирования и восстановления на уровне образов, средствах Continuous Data Protection (CDP), а также новых агентах Veeam Agent.
• В четвертой - о плагинах приложений, виртуальных модулях Backup Proxy, а также резервном копировании контейнеров и NAS-хранилищ.

В пятой части мы расскажем об улучшениях бэкап-консоли, новых функциях Enterprise Manager, возможностях установщика, лицензировании и интеграциях с хранилищами в части Primary Storage.

1. Бэкап-консоль

• Granular operations — теперь можно перезапустить процессинг или выполнить бэкап Active Full для отдельных машин без инициирования этой операции для всех машин в задаче путем клика на соответствующую машину в сессии задачи.
• Global exclusions list - управление постоянными или временными исключениями стало проще за счет возможности указания мастер-списка машин, которые вы хотите полностью исключить из процессинга, даже если они были добавлены в задачу по ошибке. Диалог Global Exclusions доступен из главного меню, также эти машины имеют выбранную опцию Disable processing на вкладке инвентаря.

• Detach backups from a job - теперь можно отключить существующие бэкапы от задачи, что влечет за собой начало новой цепочки бэкапов во время следующего запуска полного бэкапа. Отключенные бэкапы будут отображаться в Orphaned-разделе вкладки Backups с последними известными данными об их политике хранения. Если вы хотите избежать этого, то можно использовать функцию Export Backup или создать новый Copy Backup вместо отключения бэкапов.
• Dashboard redesign - дэшборды Workload и Storage registration были переработаны, чтобы упростить навигацию по растущему объему поддерживаемых платформ, вендорам хранилищ и их моделям, с которыми нативно интегрировано решение Veeam Backup & Replication.
• Last backup time - теперь в списке машин на вкладке инвентаря отображается дата и время снятия последнего бэкапа.
• Exported backup retention - если вы выбираете автоматическое удаление экспортированных, скопированных или VeeamZIP бэкапов, то дата удаления будет записана в логе сессии.
• Repository membership and role - новые колонки в представлении репозитория показывают, является ли он extent member для SOBR, а также тип экстента (Performance, Capacity или Archive).
• Instant recovery preferences - состояние чекбоксов на последней странице мастера Instant Recovery теперь сохраняется на уровне пользователя, чтобы быстрее выполнять восстановление.
• Session initiator logging - все сессии Restore and System теперь отображают аккаунт пользователя, который инициировал операцию.
• History tab improvements - все долгие активные сессии (например, без значения End Time) теперь показаны в верху списка при сортировке по End Time.
• Update notification improvements - движок оповещения об обновлениях был улучшен, теперь он включает нотификации о кумулятивных патчах.

2. Функции Enterprise Manager

Общие улучшения:

• Certificate-based authentication — теперь не нужно хранить креды бэкап-администратора для каждого управляемого бэкапа в конфигурационной базе данных. Как только бэкап-сервер регистрируется в Enterprise Manager, для коммуникации будут использоваться автоматически сгенерированные сертификаты.

• Backup server preferences - теперь запоминается выбор бэкап-серверов на дэшборде и отображается там по умолчанию.
• Improved email reports - были сделаны различные улучшения в отчете по почте в плане контента и верстки.
• Export support logs - теперь запрошенные Veeam логи могут быть экспортированы с помощью новой функции Log Export.

Улучшения резервного копирования:

• CDP for VMware Cloud Director — теперь доступно управление существующими политиками VCD CDP и их репликами в Enterprise Manager.
• Catalyst Copy jobs - можно управлять задачами HPE StoreOnce Catalyst Copy через Enterprise Manager.
• Quick backup - операции Quick Backup теперь можно запускать из Enterprise Manager для задач, управляемых агентами Managed-byServer.

• High priority jobs - теперь можно менять приоритет задач в веб-интерфейсе и видеть наиболее приоритетные задачи в списках.

Улучшения процесса восстановления:

• Instant VM Recovery - теперь выполнять восстановление машин и файловых шар VMware vSphere, VMware Cloud Director и Microsoft Hyper-V можно делать напрямую из бэкапов и снапшотов хранилищ прямо из веб-интерфейса. Это делает доступным восстановление в рамках операции Migrate to Production.
• Restore to another location - в дополнение к in-place restores, вы можете проводить полное восстановление виртуальной машины на другой хост или хранилище, а также указывать все остальные параметры размещения.
• PostgreSQL database restore - теперь можно восстанавливать экземпляры БД point-in-time из application-aware бэкапов серверов PostgreSQL и делегировать эту операцию администраторам БД и операторам техподдержки.

• VM templates restore - теперь можно искать и восстанавливать шаблоны ВМ.
• Exchange item-level restore improvements - теперь не нужно постоянной хранить аккаунт AD в БД Enterprise Manager, который является членом групп Domain Administrator или Organization Management. Вместо этого можно использовать его в интерактивном режиме с ограничениями по количеству почтовых ящиков при начале восстановления.
• Search result sorting - выполнение восстановления на уровне файлов стало проще, так как файлы отсортированы по именам в результатах поиска.

3. Установщик

• New setup experience - установщик был переработан, основные и важные функции сохранились, но были убраны лишние шаги и ненужные элементы. Теперь не нужно заботиться о предварительных условиях установки - нужно просто выбрать те чекбоксы параметров установки, которые вам доступны.

• Streamlined upgrade - существенно была улучшена функциональность предварительных проверок для апгрейда, где теперь показываются все обнаруженные проблемы в удобном для использования формате. Теперь в отчете вы можете скопировать все детали найденных проблем и отправить их коллегам для исправления.

4. Лицензирование

Прежде всего надо отметить, что формат лицензий не менялся с 10-й версии продукта, поэтому вам не нужно будет обновлять их, и можно продолжить их использование и для V12.

Veeam Universal License (VUL):

• Doubled license buffer - пользователи с функцией License auto update теперь могут использовать в два раза больший буфер лицензий, что дает возможность превысить использование лицензии VUL до 20% (или до 20 лицензий, в зависимости от того, что больше). Для этого нужно включить license update check, который должен выполняться хотя бы раз в месяц (то есть, нужно настроить сетевой экран соответствующим образом).

Улучшения Community Edition:

• Community Edition Now with even more features - обновленный бесплатный продукт Veeam Backup & Replication Community Edition V12 получил еще больше новых возможностей и улучшений, доступных в версии V12. Подробнее об этом тут.
• Cloud-native backups - решения Veeam Backup for Microsoft Azure, for AWS и for Google Cloud теперь включают издание Community Edition как часть бесплатной лицензии на 10 инстансов. Также доступен апгрейд с Community Edition на Veeam Data Platform Essentials.

5. Улучшения Primary Storage

Общие улучшения:

• Storage discovery optimizations - логика автоматического ресканирования хранилищ была переработана, чтобы избежать ненужных сканирований, которые влияют на производительность. Вследствие этого было уменьшено количество "тяжелых" операций VMFS rescan, которые теперь случаются только при сборе информации о томах и снапшотах или обновлении томов.

Новая версия Universal Storage API v2:

• Snapshot replication orchestration - задачи РК теперь могут использовать существующие связи репликации хранилищ для создания реплик на основе storage-based snapshot как дополнительных точек восстановления. Это позволяет снимать резервные копии из массивов secondary storage, чтобы избежать нагрузки на primary storage.
• Snapshot archiving orchestration - теперь задача РК может управлять offload-операциями снапшотов хранилищ на других типах хранилищ, которые поддерживаются вендором, и отслеживать их как дополнительные точки восстановления.
• Synchronous replication support - задачи РК могут создавать скоординированные снапшоты хранилищ, которые могут управляться как дополнительные точки восстановления на конфигурациях dual storage, которые служат как один том production volume из нескольких бэкэндов управления. Это предоставляет интеграцию с конфигурациями Active/Active и Active/HotStandby.

Для второй версии API (USAPI V2) пока полностью поддерживаются хранилища Pure Storage, другие вендоры будут добавляться по мере их присоединения к программе.

Хранилища Cisco HyperFlex:

• Multi-vCenter configuration support - версия V12 использует новый HyperFlex API для VMware vCenter для управления хостами ESXi в окружениях, где есть несколько кластеров HyperFlex под управлением одного или нескольких серверов vCenter.

Хранилища IBM Spectrum Virtualize:

• Volume replication orchestration - добавлена поддержка репликации снапшотов (например, Global Mirror), а также синхронной репликации (например, Metro Mirror и HyperSwap) для хранилищ типа IBM Spectrum Virtualize. Это добавляет поддержку массивов secondary storage для бэкапа из снапшотов хранилищ и задач snapshot-only.
• Compressed snapshots support - для томов IBM FlashSystem с поддержкой аппаратного сжатия в модулях IBM FlashCore функция сжатия снапшотов включена и используется по умолчанию.

HPE Nimble and HPE Alletra 5000/6000:

• Synchronous replication support — в V12 добавлена поддержка синхронной репликации и coordinated snapshots, включая конфигурации с Peer Persistence for application-transparent failover. Это дает поддержку secondary storage для бэкапов из снапшотов хранилищ и задач snapshot-only. Данная функциональность поддерживается для массивов HPE Nimble и HPE Alletra 5000/6000 на базе Nimble OS версии 5.1.4 и более поздних.

NetApp All SAN Array (ASA):

• NetApp ASA support — в V12 добавлена поддержка NetApp ASA для интеграции со снапшотами хранилищ.

На этом заканчивается список функций для пятой части статьи. В завершающей статье о Veeam Backup & Replication v12 мы расскажем о Secondary storage, бэкапе на ленту, поддержке разных платформ, новых функциях Cloud Connect, а также улучшениях API и REST API для бэкап-серверов.

Скачать пробную версию продукта можно бесплатно по этой ссылке.

На сайте virten.net появилась хорошая заметка о составе ISO-образа VMware ESXi 8.0, который является частью платформы VMware vSphere 8.

Сам гипервизор ESXi присутствует на рынке уже более 15 лет (раньше он назывался ESX и был построен поверх ОС Linux), и его состав и занимаемый объем на диске менялся со временем. Напомним, что в восьмой версии гипервизора VMware добавила компоненты esxio, обеспечивающие функционирование технологии Project Monterey и SmartNIC, а также составляющие поддержки архитектуры ARM.

Давайте посмотрим, как менялся объем гипервизора, входившего в установочный ISO-образ ESXi, от версии к версии:

• ESXi 3.5 - 46,01 MB
• ESXi 4.0 - 59,99 MB
• ESXi 4.1 - 85,19 MB
• ESXi 5.0 - 132,75 MB
• ESXi 5.1 - 125,85 MB
• ESXi 5.5 - 151,98 MB
• ESXi 6.0 - 154,90 MB
• ESXi 6.5 - 135,39 MB
• ESXi 6.7 - 129,51 MB
• ESXi 7.0 - 149,40 MB
• ESXi 8.0 - 226,62 MB

Визуализация этих цифр выгладит так:

Надо сказать, что это только размер самого гипервизора, но помимо него в установочном образе содержатся и другие элементы, такие как драйверы устройств, образы VMware Tools и другие вспомогательные библиотеки и системные компоненты.

Если посмотреть на ISO-образ VMware ESXi 8.0, то там будут следующие составные части:

Визуализация этого выглядит так:

Сейчас установочный ISO-образ весит 600-650 МБ, в зависимости от содержащихся в нем апдейтов:

Также если вы перейдете на страницу загрузки VMware ESXi, то увидите, что там есть и Offline Bundle, который занимает значительно больше места на диске, а поставляется он в формате ZIP-архива:

Этот бандл нужен в качестве источника для обновлений VMware Lifecycle Manager - он содержит не только сами компоненты ISO-образа, но и все необходимые апдейты, которые можно накатить на уже установленный гипервизор, чтобы получить актуальную версию платформы.

Недавно компания Microsoft выпустила обновление KB5022842 для Windows от 14 февраля, которое, к сожалению, приводит к неработоспособности виртуальных машин на платформе VMware vSphere 7, если для них включен режим безопасной загрузки (Secure Boot). Проблема описана вот тут (Microsoft также подтвердила со своей стороны), там же есть и PowerCLI-скрипт для выявления таких машин:

$secureBoot2022VMs = foreach($datacenter in (Get-Datacenter)) {
  $datacenter | Get-VM |
    Where-Object {$_.Guest.OsFullName -Match 'Microsoft Windows Server 2022' -And $_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled} |
      Select-Object @{N="Datacenter";E={$datacenter.Name}},
        Name,
        @{N="Running OS";E={$_.Guest.OsFullName}},
        @{N="Secure Boot";E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}},
        PowerState
}
$secureBoot2022VMs | Export-Csv -NoTypeInformation -Path ./secureBoot2022VMs.csv

При попытке запустить такую ВМ она не включится, а в логе vmware.log в папке с ВМ вы увидите такие записи:

2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Signature: 0 in db, 0 in dbx, 1 unrecognized, 0 unsupported alg.

2023-02-15T05:34:31.379Z In(05) vcpu-0 - Hash: 0 in db, 0 in dbx.

2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.

Ситуация была исправлена со стороны VMware в патче обновлений vSphere 7 Update 3k (KB 90947), который предлагается установить всем пользователям, затронутых этой ситуацией.

Отметим, что с виртуальными машинами на vSphere 8 никаких неприятностей не произошло.

Скачать VMware vSphere 7 Update 3k можно по этой ссылке. Release Notes находятся тут.

Спасибо Сергею за новость.

Компания VMware выпустила небольшое обновление хост-серверов платформы виртуализации VMware vSphere - ESXi 8.0b и vCenter 8.0b. Напомним, что о прошлом обновлении VMware vCenter 8.0a мы писали вот тут.

Из нового в ESXi 8.0b заявлена только поддержка технологиии vSphere Quick Boot для следующих серверов:

• HPE - ProLiant DL110 / DL160 / ML350 (все это Gen10)
• Lenovo ThinkSystem SR 665

Для vCenter 8.0b были сделаны только исправления некоторых багов:

• Фиксы для самого vCenter - подробнее тут
• Обновления для vSphere with Tanzu - подробнее тут
• Исправления безопасности для Photon OS - о них рассказано здесь

Скачать VMware vSphere 8.0b можно по этой ссылке.

Наш постоянный читатель Сергей обратил внимание на то, что недавно вышла новая версия средства мониторинга ИТ-инфраструктуры Zabbix 6.2, в которой есть много всего нового и полезного для наблюдения за виртуальной инфраструктурой VMware vSphere.

Давайте посмотрим, что там интересного в плане работы с хостами vSphere:

• Возможность вручную назначать шаблоны обнаруженным хостам ESXi
• Создание и изменение пользовательских макросов для обнаруженных хостов ESXi
• Добавление дополнительных тэгов для серверов

Также функции мониторинга были доработаны, чтобы поддерживать новые сущности и низкоуровневые правила их обнаружения.

Это позволяет отслеживать новые метрики, а именно:

• Статус алармов серверов
• Число снапшотов и время их создания
• Метрики сетевых интерфейсов ESXi
• Метрики портов распределенного коммутатора vSphere Distributed Switch
• Метрики IOPS read/write для датасторов
• Другие счетчики производительности датасторов
• Состояние гостевых ОС

• Прочие метрики из разных категорий

Также теперь обнаружение хостов VMware vSphere может быть отфильтровано на базе их статуса включенности (например, можно добавить только работающие сейчас хосты ESXi).

Более подробно о новой версии Zabbix 6.2 можно почитать на этой странице. Скачать продукт можно тут.

Многие пользователи уже применяют новую версию платформы виртуализации VMware vSphere 8 в своих производственных средах. Как обычно, после обновления платформы обновляется и сертификация VMware Certified Professional (VCP), которая теперь доступна в варианте для vSphere 8.x в рамках трека Datacenter Virtualization (VCP-DCV 2023).

Сам экзамен по vSphere 8 доступен по этой ссылке, где вы можете выбрать удобное вам время для сдачи. Экзамен, само собой, доступен на английском языке и за пределами России. Вот основные его разделы:

• Section 1 – Architecture and Technologies
• Section 2 – Products and Solutions
• Section 3 – Planning and Designing
• Section 4 – Installing, Configuring, and Setup
• Section 5 – Performance-tuning, Optimization, and Upgrades
• Section 6 – Troubleshooting and Repairing
• Section 7 – Administrative and Operational Tasks

Официальное руководство к экзамену с примерами тестов вы можете скачать по этой ссылке. В экзамене содержится 70 вопросов, а проходной бал, как и обычно, составляет 300. Записаться на сдачу можно по этой ссылке, стоит он $250. Официальные курсы по подготовке к экзамену доступны тут.

Ну и напомним, как сейчас выглядит путь сертификации инженеров VMware:

Многие пользователи применяют сценарии PowerCLI (недавно, кстати, вышла 13-я версия этого пакета) для автоматизации виртуальной инфраструктуры VMware vSphere на базе фреймворка PowerShell.

При этом для скриптов часто встает вопрос безопасного хранения данных учетных записей (логин-пароль), чтобы не указывать их прямым текстом в исходниках сценариев. Компонент PowerCLI credential store использует хранилище учетных записей, которое, в свою очередь, использует Windows data protection API для шифрования данных учетных записей и хранения их в файле. Поэтому PowerCLI credential store доступен только в Windows и не является кроссплатформенным. А что насчет пользователей Linux и MacOS?

Некоторое время назад Microsoft выпустила два полезных кроссплатформенных модуля SecretManagement и SecretStore (подробнее об этом тут). SecretManagement предоставляет командлеты, которые позволяют пользователям управлять паролями в различных хранилищах, а SecretStore - это, собственно, само хранилище и есть. Эти два модуля можно использовать вместо стандартного хранилища VICredential. Чтобы проиллюстрировать, как работать с ними, в VMware сделали пример модуля с разными версиями командлетов VICredential.

Первый шаг - это регистрация и конфигурация защищенного хранилища. В примере использования модуля, упомянутом выше, можно использовать Initialize-VISecret, который реализует эту процедуру - регистрирует SecretStore как хранилище по умолчанию и настраивает окружение так, чтобы пароль не запрашивался при доступе к хранилищу.

function Initialize-VISecret {

[CmdletBinding()]

param(

[string]$Vault = "VMwareSecretStore"

)
 process {

  Set-SecretStoreConfiguration -Scope CurrentUser -Authentication None -Interaction None -Confirm:$false 

           Register-SecretVault -Name $Vault -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

  }

  }

Этот режим по пользовательскому опыту близок к VICredentialStore, так как пароли хранятся в зашифрованном виде, но сам пароль при доступе к нему не запрашивается. В примере используется SecretStore по умолчанию, но можно изменить хранилище на любое по вашему выбору, а именно:

• Azure KeyVault (продукт Microsoft)
• KeePass
• LastPass
• Hashicorp Vault
• KeyChain
• CredMan

Чтобы сохранить креды в хранилище, нужно использовать командлет Set-Secret модуля SecretManagement. Сами креды в этом командлете идентифицируются по имени, но в примере ниже креды описываются двумя идентификаторами - имя пользователя и сервер, к которому нужно получить доступ. Такими образом, командлет New-VISecret склеивает строки "VISecret", сервер и имя пользователя в один идентификатор, который и используется для получения пароля.

Если вы хотите сохранить креды более чем для одного продукта, вы можете изменить функцию так, чтобы заменить VISecret на другую специфичную для продукта строку, чтобы создать идентификатор, например, "VMCSecret" для VMware Cloud. Можно передавать пароль простым текстом или в виде защищенной строки.

Также вы можете удалить креды из хранилища, используя командлет Remove-VISecret, который создает идентификатор и вызывает функцию Remove-Secret для удаления кредов. Если вы используете SecretStore в качестве хранилища, вы можете очистить его полностью с помощью функции Reset-SecretStore.

Создание нового идентификатора выглядит так:

function New-VISecret {
    [CmdletBinding()]
    [Alias("Set-VISecret")]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [string]$Password,
        [securestring]$SecureStringPassword,
        [string]$Vault
    )
    begin {
        if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
            Throw "Either Password or SecureStringPassword parameter needs to be specified"
        }
        if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
            Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
        }
    }
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
         if ($password) {
            $params += @{"Secret" = $password}
        } elseif ($secureStringPassword) {
            $params += @{"SecureStringSecret" = $secureStringPassword}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Set-Secret @params
    }
}

Получение кредов из хранилища выглядит так:

function Get-VISecret {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Server,
        [Parameter(Mandatory=$true)]
        [string]$User,
        [switch]$AsPlainText,
        [string]$Vault
    )
    process {
        $params = @{
            "Name" = "VISecret|"+$server+"|"+$User
        }
        if ($AsPlainText.IsPresent) {
            $params += @{"AsPlainText" = $AsPlainText.ToBool()}
        } elseif ($Vault) {
            $params += @{"Vault" = $Vault}
        }
        Get-Secret @params
    }
}

Последний командлет в примере - это Connect-VIServerWithSecret. Он сочетает в себе оба командлета, приведенных выше, что дает интегрированный инструмент для работы по аналогии с командлетом Connect-VIServer для VICredentialStore. Вы можете вызвать Connect-VIServerWithSecret с логином и паролем, но использовать параметр -SaveCredentials для сохранения кредов в хранилище.

После этого вы можете опускать параметры учетной записи, а Connect-VIServerWithSecret будет автоматически получать пароль из хранилища и соединяться с сервером vCenter. При использовании VICredentialStore, если у вас сохранены креды только к одному серверу, вы можете соединяться с ним через Connect-VIServer без указания имени пользователя. А для использования функции Get-Secret параметр -Username является обязательным, так как не проверяется, что в хранилище сохранена только одна учетная запись. Чтобы упростить жизнь в этом случае есть глобальная переменная $global:defaultUser, значение которой и будет использоваться в Connect-VIServerWithSecret.

Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:

• Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
• При включении ВМ вы получаете ошибку " File not found"
• Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
• Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено

Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.

В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:

Часть 1 - восстановление основного VMDK виртуальной машины

Перед выполнением операций ниже обязательно сохраните полную копию папки виртуальной машины, и только после этого проводите все описанные ниже операции. Если у вас есть резервная копия виртуальной машины, и ее восстановление вас устраивает - то лучше сделать эту операцию вместо описанной ниже процедуры исправления дисков, так как вероятность ошибиться в ней велика.

Если вкратце, то для восстановления вам нужно выполнить следующие шаги:

1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.

2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk

Делается это командой:

# ls -l <имя диска>-flat.vmdk

На выходе мы получим размер диска в байтах. Вывод будет выглядеть примерно так:

3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:

# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk

После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).

4. Открываем переименованный дескрипторный файл VMDK и меняем выделенные красным строчки:

# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 8388608 VMFS "vmdisk0-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

Если у изначальной машины диск был не растущим по мере наполнения (thin disk), то последнюю строчку, выделенную красным, можно не добавлять.

Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.

Консистентность виртуальной машины можно проверить командой:

vmkfstools -e filename.vmdk

Если все в порядке, то в ответе команды вы получите вот такую строчку:

Disk chain is consistent.

Если же исправить ситуацию не получилось, то будет вот такой текст:

Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).

После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.

Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)

Ситуация усложняется, когда у исходной виртуальной машины были снапшоты, тогда папка с ней выглядит следующим образом (красным выделены важные для нас в дальнейших шагах файлы):

drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf

Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):

1. Определяем нужные нам файлы

Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).

Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.

2. Создаем новый дескриптор снапшота

Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:

# cp examplevm.vmdk examplevm-000001.vmdk

3. Меняем указатели на файл с данными для снапшота

Теперь нужно открыть созданный файл в текстовом редакторе и начать его исправлять. Пусть он выглядит вот так:

ddb.virtualHWVersion = "7"
ddb.longContentID = "5fd87dda1dc77cafd5be881a19741890"
ddb.uuid = "60 00 C2 9e 3d 8d 45 82-dd 1f e4 93 22 da 9c 61"
ddb.geometry.cylinders = "1958"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.

С данным файлом нужно сделать следующие манипуляции:

• Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
• Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
• Строчку createType="vmfs" заменяем на createType="vmfsSparse"
• Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)

4. Добавляем данные специфичные для снапшота

Теперь нам надо добавить в указатель снапшота кое-что новое:

• Под строчкой createType="vmfsSparse" добавляем строчку parentFileNameHint="examplevm.vmdk"

Ну и теперь надо убрать лишнее. Удаляем из файла следующие строчки, которые нужны только для основного родительского диска:

Ну а вот эту строчку нужно оставить:

ddb.longContentID = "5fd87dda1dc77cafd5be881a19741890"

Таким образом, содержимое результирующего файла должно быть следующим:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=7f3a1e17
parentCID=19741890
createType="vmfsSparse"
parentFileNameHint="examplevm.vmdk"

# Extent description
RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "5fd87dda1dc77cafd5be
881a19741890"

После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:

vmkfstools -e filename.vmdk

Ну и помните, что все эти действия по цепочке вы можете провернуть для следующих уровней дочерних снапшотов, если их диски с данными в порядке. Главное - не забывайте делать резервные копии перед любыми операциями!

На днях обновилась известная многим администраторам виртуальной инфраструктуры утилита RVTools до версии 4.4.1. Напомним, что она предназначена для помощи пользователю VMware vSphere в различных аспектах при выполнении рутинных операций в виртуальной среде серверов ESXi и виртуальных машин. В прошлый раз об RVTools 4.3.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в RVTools 4.4.1:

• Теперь утилита разрабатывается на Visual Studio 2022.
• RVTools использует обновленный VMware vSphere Management SDK 8.0.
• Log4net обновлен до версии 2.0.15.
• Компонент RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля.
• Новые колонки на странице vInfo: емкость диска в MiB, Folder ID, роль Fault tolerance, операции Reboot/Poweroff, опция EFI Secure boot, SMBIOS UUID.
• Новая колонка на странице vCPU - Numa Hotadd Exposed. Это булевое значение, показывающее работает ли NUMA-топология при включенном CPU hotadd.
• Новые колонки на странице vDisk: Disk UUID и Disk sharing mode.
• На всех страницах, относящихся к ВМ, колонка с тэгами поставлена перед колонкой Datacenter. Также изменен текст тултипа VM UUID на "VirtualCenter-specific 128-bit UUID of a virtual machine".
• Новые колонки на странице vSource: version, patch level и VI SDK Server.
• На странице vHealth путь /storage/archive исключен из проверки free disk capacity, так как этот раздел может быть заполнен изначально в нормальной конфигурации (подробнее тут).
• Исправлена ошибка с некорректным отображением колонки Primary IP Address на странице vInfo.
• Решена проблема на странице vNetwork, когда нельзя было понять, является ли IP-адрес типом ipv4 или ipv6.

Скачать новую версию RVTools 4.4.1 можно по этой ссылке. Описание отображаемых параметров находится тут.

Многие администраторы и разработчики, вовлеченные в управление виртуальной инфраструктурой VMware vSphere и использующие ее компоненты, а также другие решения VMware, часто планируют разработку сценариев и программ для автоматизации различных операций в виртуальной среде. Для этого VMware предоставляет комплект пакетов разработки (Software Development Kits, SDK), которые стандартизируют разработку сторонних решений на различных языках (Java, .NET, Perl, Python, Ruby и других).

Первое, что надо посетить в этом случае - это единая страница для всех VMware SDK:

Вторая страница - это комплект SDK, в том числе от партнеров и в рамках различных программ для разработчиков. Находится она здесь.

Что касается специальных программ для разработчиков (например, партнеров по программе Technology Alliance Partner, TAP), то информация о них доступна на этой странице (так называемые Gated SDK).

Кроме того, некоторые SDK, до выхода vSphere 8, были доступны только в соответствующих репозиториях на GitHub. Теперь их перенесли в единый центр загрузки. Вот их новые страницы:

• pyVmomi
• vSphere Automation SDK for Python 
• vSphere Automation SDK for Java

Также разработчикам следует обратить внимание и на страницу Developer Tools:

На днях наш ценный читатель (и подсказыватель правильных вещей) Сергей заметил, что мы давно не упоминали об обновлениях средства SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали о нем осенью 2018 года вот тут (это был релиз White Forest).

Напомним, что это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

C 2018 года вышло 4 больших релиза SexiGraf, давайте рассмотрим их возможности вкратце.

Вот что появилось в релизе Traptown:

• SuperStats - новые метрики уровня кластера, включающие в себя такие объекты, как hba, network, storage, power 
• vCenter Bad Events - возможность отслеживания "плохих" событий в инфраструктуре на уровне vCenter
• Поддержка Early Storage Pod (aka Datastore Cluster) - теперь если у вас есть кластер хранилищ на базе Storage Pod, то теперь можно выводить его агрегированные метрики
• Поддержка Grafana 4.6.5

В релиз Ravenholm было добавлено следующее:

• Поддержка Unmanaged ESXi (без сервера vCenter)
• Поддержка сенсоров ESX Hardware Sensors
• Новая версия Grafana 7.3.x
• Поддержка Graphite 1.1.x
• Поддержка решения pfSense (через плагин Telegraf)
• Поддержка данных S.M.A.R.T. (через кастомные сценарии)
• Модуль основан на Ubuntu 16.04 LTS
• Функции Netdata - это Apache-скорингборд и дэшборд не базе graphite carbon для мониторинга виртуального модуля SexiGraf

Новые возможности релиза Highway 17:

• Powershell вместо Perl для сбора метрик VMware
• Функции vSAN SMART Stats
• Обобщенные метрики vSAN Monitor Network
• Новый инвентарь для ВМ и серверов ESXi
• Поддержка PowerShell core 7.2.1
• Поддержка PowerCLI 12.5.0
• Поддержка Grafana 8.4.4
• Сделано на Ubuntu 20.04.4 LTS

Обновления релиза Victory Mine (а вышел он 3 недели назад):

• Поддержка архитектуры vSAN 8 ESA
• Datastore inventory - инвентаризация объектов хранилищ
• DRS Score dashboard - дэшборд под метрику DRS Score
• Поддержка PowerShell core 7.2.7 LTS
• Поддержка PowerCLI 13.0
• Поддержка Grafana 8.5.15
• Работает на Ubuntu 20.04.5 LTS

Полный список всех обновлений SexiGraf и обзор новых функций можно найти на этой странице. Скачать виртуальный модуль в формате OVA можно по этой ссылке. Однако, как было отмечено, из России он не качается, поэтому перед скачиванием нужно включить VPN.

В самом конце ушедшего года компания VMware обновила главный документ о производительности своей флагманской платформы виртуализации - Performance Best Practices for VMware vSphere 8.0. Напомним, что в последний раз об этом документе мы писали, когда с пакетом обновлений Update 3 долгое время были проблемы (в том числе с производительностью), а в итоге стала доступна стабильная версия обновления vSphere 7.0 Update 3c.

Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere
• ESXi and Virtual Machines
• Guest Operating Systems
• Virtual Infrastructure Management

Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках. В основном, документ повторяет рекомендации, которые приводились для прошлых версий платформы, но есть и пункты, касающиеся непосредственно vSphere 8 и ESXi 8:

Документ очень полезный, состоит ровно из ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.

Скачать Performance Best Practices for VMware vSphere 8.0 можно по этой ссылке.

Как написали коллеги с сайта virten.net, при установке платформы VMware ESXi 7 или 8 на сервер с процессорами Intel Core 12 поколения возникает розовый экран смерти (PSOD), содержащий следующие сообщения:

HW feature incompatibility detected; cannot start

Fatal CPU mismatch on feature "Hyperthreads per core"
Fatal CPU mismatch on feature "Cores per package"
Fatal CPU mismatch on feature "Cores per die"

Проблема здесь заключается в том, что новая архитектура процессоров Intel идет с ядрами двух типов - Performance-cores и Efficient-cores. Начиная с vSphere 7.0 Update 2, в ядро гипервизора был добавлен параметр cpuUniformityHardCheckPanic для того, чтобы избежать подобной проблемы, которая проявляется в следующих версиях платформы виртуализации:

• vSphere / ESXi 8.0 или более поздние
• vSphere / ESXi 7.0 Update 2 или более поздние

1. Итак, в самом начале установки ESXi нажимаете SHIFT+O, чтобы изменить параметры загрузки. Далее в появившейся строке вводите:

cpuUniformityHardCheckPanic=FALSE

2. После этого нажимаете Enter и дожидаетесь окончания установки.

3. Затем во время первой загрузки опять нажимаете SHIFT+O и вводите ту же самую строчку.

4. А уже когда гипервизор загрузится, нужно добавить следующую строчку в параметры ядра, чтобы отключить проверку, а ESXi не вылетал в розовый экран при каждой загрузке:

# esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE

Также есть метод, описанный для установки через механизм автоматизированного развертывания Kickstart:

1. Создаем флэшку USB с ISO-образом ESXi, как написано здесь.

2. Открываем файл /efi/boot/boot.cfg в редакторе и добавляем следующую опцию в строчку kernelopt= параметров ядра:

ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE

3. Далее вам надо создать файл /KS.CFG для конфигурации Kickstart и в секциях  %post (пост-параметры установки, но до первой загрузки) и %firstboot (первая загрузка) добавить следующее:

vmaccepteula

  install --firstdisk=usb --overwritevmfs
network --bootproto=static --ip=192.168.0.26 --netmask=255.255.255.0 --gateway=192.168.0.1 --hostname=esx12.virten.lab --nameserver=192.168.0.1

  rootpw VMware1!
%post --interpreter=busybox
/bin/mcopy -o -i /dev/disks/mpx.vmhba32\:C0\:T0\:L0\:5 ::BOOT.CFG /tmp/BOOT.cfg

  /bin/sed -i '/kernelopt/s/$/ cpuUniformityHardCheckPanic=FALSE/' /tmp/BOOT.cfg

  /bin/mcopy -o -i /dev/disks/mpx.vmhba32\:C0\:T0\:L0\:5 /tmp/BOOT.cfg ::BOOT.CFG

  /bin/reboot
%firstboot --interpreter=busybox
# Enable SSH

  vim-cmd hostsvc/enable_ssh

  vim-cmd hostsvc/start_ssh
# Enable ESXi Shell

  vim-cmd hostsvc/enable_esx_shell

  vim-cmd hostsvc/start_esx_shell
# Suppress Shell warning

  esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1
# Disable CPU Uniformity Check

  localcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE 
# SSH Key

  cat > /etc/ssh/keys-root/authorized_keys <<EOF

  ssh-rsa AAAAB3N[...] yourname

  EOF
# NTP

  esxcli system ntp set -s pool.ntp.org

  esxcli system ntp set -e 1

4. Далее можете провести установку с USB-флэшки, а через пару минут вы уже сможете получить доступ к ESXi через консоль или по SSH.

5. Если вы используете механизм Secure Boot, то обычно секция %firstboot не применяется (так работает по умолчанию на большинстве систем). Поэтому вам потребоваться ввести команды этой секции вручную или отключить Secure Boot. С командами раздела %post все будет в порядке.

6. По окончании установки через Kickstart все будет работать:

Как вы знаете, главным релизом этого года стала новая версия платформы VMware vSphere 8, где появилось множество новых возможностей и улучшений уже существующих технологий. Одной из интересных функций стала vSphere Virtual Topology.

Для виртуальных машин с Hardware version 20 теперь доступно простое конфигурирование vNUMA-топологии для виртуальных машин:

Для виртуальных машин теперь доступна информационная панелька CPU Topology с конфигурацией vNUMA:

Недавно компания VMware выпустила документ "vSphere 8.0 Virtual Topology Performance Study", где рассматриваются аспекты производительности новой технологии, которую назвали vTopology. Виртуальная топология CPU включает в себя такие техники, как virtual sockets, узлы virtual non-uniform memory access (vNUMA), а также механизм кэширования virtual last-level caches (LLC).

До vSphere 8.0 дефолтной конфигурацией виртуальных машин было одно виртуальное ядро на сокет - это в некоторых случаях создавало затыки в производительности и неэффективность использования ресурсов. Теперь же ESXi автоматически подстраивает число виртуальных ядер на сокет для заданного числа vCPU.

На картинке ниже показана высокоуровневая архитектура компонентов двухсокетной системы. Каждый сокет соединен с локальным узлом памяти (memory bank) и образует с ним NUMA-узел. Каждый сокет имеет 4 ядра (он имеет кэши L1 и L2), а ядра шарят между собой общий кэш last-level cache (LLC).

Когда создается виртуальная машина с четырьмя vCPU, в vSphere она конфигурируется на одном сокете, вместо четырех, как это было ранее:

Так это выглядит в выводе команды CoreInfo для двух рассмотренных топологий:

Слева - это старая конфигурация, где был один vCPU на сокет, а справа - 4 vCPU (виртуальных ядер ВМ) на один сокет.

В указанном документе VMware проводит различных конфигураций (от 8 до 51 vCPU на машину) для разных нагрузок с помощью бенчмарков и утилит DVD Store 3.5, Login VSI, VMmark, Iometer, Fio и Netperf в операционных системах Windows и Linux. Забегая вперед, скажем, что для нагрузок Oracle прирост производительности составил 14%, а для Microsoft SQL server - 17%.

Итак, результаты теста DVD Store для БД Oracle:

Статистики NUMA hits NUMA misses для гостевой ОС Linux:

Результаты тестов для Microsoft SQL server:

Результаты тестирования хранилищ с помощью IOmeter:

Производительность в разрезе метрики CPU cycles per I/O (CPIO):

Результаты тестов для NVMe хранилищ:

Результаты тестов сети и другие выводы вы можете найти в документе "VMware vSphere 8.0 Virtual Topology Performance Study".

На прошедшей осенью этого года главной конференции о виртуализации Explore 2022 компания VMware сделала немало интересных анонсов, главным из которых стал выпуск новых версий платформ vSphere 8 и vSAN 8. На американской и европейской конференциях много говорили о будущих новых продуктах и технологиях VMware, но несколько незамеченным остался переход VMware на новую схему релизов платформы vSphere...

За релизами платформы VMware vSphere 8, у которой недавно состоялся выпуск General Availability, многие забыли о том, что большинство пользователей в производственной среде используют еще VMware vSphere 7. Недавно компания VMware выпустила обновления компонентов этой версии платформы - ESXi 7.0 Update 3i (на 13 декабря почему-то недоступен для скачивания) и vCenter 7.0 Update 3i. Напомним, что об обновлении VMware vSphere 7 Update 3f мы писали вот тут (а здесь - о возможностях Update 3), с тех пор вышел еще апдейт 3g, а сегодня мы расскажем об очередном пакете - 3i.

Давайте посмотрим, что нового в ESXi 7.0 Update 3i:

• Поддержка функций vSphere Quick Boot для сервера HPE ProLiant MicroServer Gen10 Plus v2
• Исправления для уязвимостей CVE-2022-31696 и CVE-2022-31699, описанных в статье VMSA-2022-0030

В VMware vCenter 7.0 Update 3i появились следующие улучшения:

• Исправления ошибок, список которых приведен здесь
• Исправления для уязвимостей CVE-2022-31697 и CVE-2022-31698, описанных в статье VMSA-2022-0030
• Исправление для уязвимости CVE-2021-22048, описанное в статье VMSA-2021-0025
• Обновление решения VMware vSphere with Tanzu (подробнее - в Release Notes)
• Обновление Photon OS (подробнее тут, в основном патчи безопасности)

Как мы видим, обновления чисто косметические, но исправлены некоторые актуальные проблемы безопасности, поэтому обновиться стоит. Очевидно, что новый функционал в vSphere 7 добавляться уже не будет, так как идет работа над обновлением vSphere 8.

Скачать VMware ESXi 7.0 Update 3i и VMware vCenter 7.0 Update 3i можно по этой ссылке.